| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
In preparation for the FileCheck enhancement to support backreferences.
llvm-svn: 169090
|
|
|
|
| |
llvm-svn: 169089
|
|
|
|
|
|
| |
bot. Approved by d0k.
llvm-svn: 169088
|
|
|
|
|
|
| |
phabricator's command line tool.
llvm-svn: 169086
|
|
|
|
| |
llvm-svn: 169078
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 169077
|
|
|
|
|
|
|
| |
an implicit special member, rather than sometimes using '!hasDeclared<special
member>'. No functionality change.
llvm-svn: 169075
|
|
|
|
|
|
|
|
|
| |
consistent.
Fixes a crash printing diagnostics on the gcc testsuite, and also makes
diagnostic range printing print nicer results for token pastes.
llvm-svn: 169068
|
|
|
|
|
|
| |
a while.
llvm-svn: 169066
|
|
|
|
|
|
| |
scope when dealing with nested blocks. Fixes <rdar://problem/12778708>.
llvm-svn: 169065
|
|
|
|
|
|
| |
knows what they're doing here.
llvm-svn: 169059
|
|
|
|
| |
llvm-svn: 169058
|
|
|
|
|
|
|
|
|
|
| |
state so that all of the various clones end up rendering their
diagnostics into the same serialized-diagnostics file. This is
important when we actually want failures during module build to be
reported back to the translation unit that tried to import the
not-yet-built or out-of-date module. <rdar://problem/12565727>
llvm-svn: 169057
|
|
|
|
|
|
|
| |
the output size is greater than the register size. No truncation occurs with
those. Reword warning to make it clearer what's the problem is.
llvm-svn: 169054
|
|
|
|
|
|
|
|
| |
with a signed fixed type.
<rdar://problem/12780159>.
llvm-svn: 169051
|
|
|
|
| |
llvm-svn: 169045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
module, provide a module import stack similar to what we would get for
an include stack, e.g.,
In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module
<rdar://problem/12696425>
llvm-svn: 169042
|
|
|
|
| |
llvm-svn: 169041
|
|
|
|
|
|
| |
in a logical operator.
llvm-svn: 169037
|
|
|
|
| |
llvm-svn: 169030
|
|
|
|
|
|
| |
to pravic!
llvm-svn: 169028
|
|
|
|
|
|
| |
files are loaded.
llvm-svn: 169027
|
|
|
|
|
|
|
|
|
| |
building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.
llvm-svn: 169021
|
|
|
|
|
|
| |
Patch by Edwin Vane.
llvm-svn: 169000
|
|
|
|
| |
llvm-svn: 168994
|
|
|
|
|
|
|
| |
the beginning and end of the range are in different macro arguments.
PR14399.
llvm-svn: 168984
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 168977
|
|
|
|
| |
llvm-svn: 168968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If 'x' is a temporary, x.getAs<Foo>() may not be safe if the result is
supposed to persist (if its address is stored somewhere). Since getAs()
can return a null value, the result is almost always stored into a
variable, which of course is not safe when the original value dies.
This has caused several bugs with GCC's "Temporaries May Vanish Sooner Than
You Expect" optimization; in C++11 builds, at least, we'll be able to catch
these problems now.
I would suggest applying these to other getAs() and get*As() methods
(castAs is "better" because sometimes the result is used directly, which
means the temporary will still be live), but these two have both caused
trouble in the analyzer in the past.
llvm-svn: 168967
|
|
|
|
| |
llvm-svn: 168962
|
|
|
|
|
|
|
|
|
|
|
|
| |
import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.
Fixes <rdar://problem/12552849>.
llvm-svn: 168961
|
|
|
|
| |
llvm-svn: 168959
|
|
|
|
| |
llvm-svn: 168958
|
|
|
|
| |
llvm-svn: 168957
|
|
|
|
| |
llvm-svn: 168956
|
|
|
|
| |
llvm-svn: 168953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
features of ASan:
1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.
llvm-svn: 168950
|
|
|
|
|
|
|
| |
Note: the ":" goes into the regex because FileCheck wrongly complains about
unbalanced brackets otherwise.
llvm-svn: 168934
|
|
|
|
|
|
| |
before libstdc++ like we do with ubsan.
llvm-svn: 168918
|
|
|
|
| |
llvm-svn: 168908
|
|
|
|
| |
llvm-svn: 168907
|
|
|
|
|
|
|
|
| |
Original commit message:
Remove redundant code.
llvm-svn: 168900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among other differences, GCC accepts
typedef int IA[];
typedef int A10[10];
static A10 *f(void);
static IA *f(void);
void g(void) {
(void)sizeof(*f());
}
but clang used to reject it with:
invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')
The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.
Doing the type merging required some extra fixes:
* Use the type from the function type in initializations, even if an parameter
is available.
* Fix the merging of the noreturn attribute in function types.
* Make CodeGen handle the fact that an parameter type can be different from
the corresponding type in the function type.
llvm-svn: 168895
|
|
|
|
|
|
| |
stuff. Conditioning-out in macro argument was not accepted on MS cl.exe.
llvm-svn: 168867
|
|
|
|
|
|
|
|
|
| |
according to r168856, for now.
I think "i128", that I conditioned out, could be completely removed.
MS Compiler doesn't accept i128. We can assume no one would use i128.
llvm-svn: 168865
|
|
|
|
|
|
| |
mangling templates
llvm-svn: 168862
|
|
|
|
|
|
|
| |
'getPointerWidth(0) >= 64' test to be a method on TargetInfo, ready to be
properly cleaned up.
llvm-svn: 168856
|
|
|
|
| |
llvm-svn: 168855
|
|
|
|
| |
llvm-svn: 168851
|
|
|
|
|
|
|
|
|
|
|
| |
performed, to determine whether that special member is deleted or constexpr.
That overload resolution process can in turn trigger the instantiation of a
template, which can do anything, including triggering the declaration of that
very same special member function. When this happens, do not try to recursively
declare the special member -- that's impossible. Instead, only try to realise
the truth. There is no special member.
llvm-svn: 168847
|