The use of this flag enables a modules optimization where a given set
of macros can be labeled as "ignored" by the modules
system. Definitions of those macros will be completely ignored when
building the module hash and will be stripped when actually building
modules. The overall effect is that this flag can be used to
drastically reduce the number of
Eventually, we'll want modules to tell us what set of macros they
respond to (the "configuration macros"), and anything not in that set
will be excluded. However, that requires a lot of per-module
information that must be accurate, whereas this option can be used
more readily.
Fixes the rest of <rdar://problem/13165109>.
llvm-svn: 174560
This can happen when one abuses precompiled headers by passing more -D
options when using a precompiled hedaer than when it was built. This
is intentionally permitted by precompiled headers (and is exploited by
some build environments), but causes problems for modules.
First part of <rdar://problem/13165109>, detecting when something when
horribly wrong.
llvm-svn: 174554
This was GCC's option to turn on UCN support, which we always have on now
in C99 and C++ modes.
Additionally, mark the -fno-extended-identifiers option as unsupported,
since we don't support disabling UCNs in C99 and C++ modes.
PR11538
llvm-svn: 174530
This is a "quick fix".
The underlining issue is that when a const pointer to a struct is passed
into a function, we do not invalidate the pointer fields. This results
in false positives that are common in C++ (since copy constructors are
prevalent). (Silences two llvm false positives.)
llvm-svn: 174468
This is to ensure that GlobalOpt in LLVM does not attempt to look through a
selector reference to a method var name at compile time.
I also added a test/updated old tests that need to recognize the new keyword.
rdar://12580965.
llvm-svn: 174461
This is a more natural order of evaluation, and it is very important
for visualization in the static analyzer. Within Xcode, the arrows
will not jump from right to left, which looks very visually jarring.
It also provides a more natural location for dataflow-based diagnostics.
Along the way, we found a case in the analyzer diagnostics where we
needed to indicate that a variable was "captured" by a block.
-fsyntax-only timings on sqlite3.c show no visible performance change,
although this is just one test case.
Fixes <rdar://problem/13016513>
llvm-svn: 174447
since only one of them is allowed in command-line, process them separately.
Otherwise, if more than one is specified in the command-line, one is processed normally
and the others are going to be treated and included as header files.
Related to radar://13140508
llvm-svn: 174385
This is an improvement of r173630, that handles the following case:
struct VirualDestrClass
{
VirualDestrClass(int arg);
virtual ~VirualDestrClass();
};
struct ConstrWithCleanupsClass
{
ConstrWithCleanupsClass(const VirualDestrClass& cplx = VirualDestrClass(42));
};
ConstrWithCleanupsClass cwcNoArg;
That was printed as:
ConstrWithCleanupsClass cwcNoArg();
llvm-svn: 174296
This can yield dramatic speedups of dynamic_cast for simple inheritance trees,
at least with libsupc++. Neither libcxxabi nor libcxxrt make use of this
hint currently, it was never implemented because clang didn't support it.
There was some concern about the number of class hierarchy walks this change
introduces. If it turns out to be an issue we can add caching either at the cast
pair level or even deeper, but we also do a lot of walks in Sema so this
codepath is probably fairly optimized already.
llvm-svn: 174293
- Relax a expression for arm-gnueabi.
- Exclude msvc to limit target triplets to add limited a few targets.
Feel free to remove actions if guys thought they redundant.
llvm-svn: 174278
...again. The problem has not been fixed and our internal buildbot is still
getting hangs.
This reverts r174212, originally applied in r173951, then reverted in r174069.
Will not re-apply until the entire project analyzes successfully on my
local machine.
llvm-svn: 174265
designator" diagnostic with more correct and more human-friendly "cannot take
address of rvalue of type 'T'".
For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully
saying "cannot take address of rvalue of type '<overloaded function type>'".
For the case of &array_temporary, treat it just like a class temporary
(including allowing it as an extension); the existing diagnostic wording
for the class temporary case works fine.
llvm-svn: 174262
This addresses several (not all) debug info tests that use explicit metadata
numbers. Wherever the same number appeared more than once in a test I used
a named match to ensure the same number appeared in all those cases (this may
still be overly constraining test cases as they may not have actually cared
about that relationship). For one-off numbers I just replaced them with an
unnamed regex.
This may underconstrain poorly written test cases that were interested in
checking that certain metadata nodes were related but didn't actually match
on all the related nodes numbers.
llvm-svn: 174247
Inlining these functions is essential for correctness. We often have
cases where we do not inline calls. For example, the shallow mode and
when reanalyzing previously inlined ObjC methods as top level.
llvm-svn: 174245
says, but that's a defect (to be filed). "Cls::purevfn()" is still an odr use.
Also fixes a bug that caused us to not mark the function referenced just
because we didn't want to mark it odr used.
llvm-svn: 174242
Different modules may have different views of the various "special"
types in the AST, such as the redefinition type for "id". Merge those
types rather than only considering the redefinition types for the
first AST file loaded.
llvm-svn: 174234
This change introduces a 'kind' attribute for the <Para> tag, that captures the
kind of the parent block command.
For example:
\todo Meow.
used to be just <Para>Meow.</Para>, but now it is
<Para kind="todo">Meow.</Para>
llvm-svn: 174216
This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2 = r;
CGRect r3 = r2;
Previously we only made this optimization if the struct did not begin with
an aggregate member, to make sure that we weren't picking up an LCV for
the first field of the struct. But since LazyCompoundVals are typed, we can
make that inference directly by comparing types.
This is a pure optimization; the test changes are to guard against possible
future regressions.
llvm-svn: 174211
r173593 made us a little too eager to associate all code at the end of a
function with the user-written 'return' line. This caused problems with
breakpoints as they'd be set in exception handling code preceeding the
actual non-exception return handling code, leading to the breakpoint never
being hit in non-exceptional execution.
This change restores the pre-r173593 exception handling line information where
the cleanup code is associated with the '}' not the return line.
llvm-svn: 174206
Prior to the patch, Clang does not properly promote types when a complex
integer operand is combined with an integer via a binary operator, or when
one is assigned to the other in either order. This patch detects when
promotion is needed (and permissible) and generates the necessary code.
The test assmes no target has the same size operands for "char" and
"long long," and that no target performs arithmetic on char operands without
extending them to a larger format first. If there are any targets for
which this is not the case, they should be XFAILed.
llvm-svn: 174181
Fariborz Jahanian