It was too late to set BUG_REPORT_URL after configure_file(config.h).
BUG_REPORT_URL in config.h.cmake would be updated at 2nd run of cmake.
It caused many recompilations.
FYI, configure handles BUG_REPORT_URL in llvm side.
llvm-svn: 199076
Also regroup these flags so that alike flags are next to each other, while
keeping the list still mostly alphabetical.
The help text isn't ideal, but I feel it's less maze-like than
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Preprocessor-Options.html (look
at the entry for '-MMD' and count how many other entries you need to look up
until you know what it does).
And it looks like -M / -MM are mostly an historical accident and most people
use -MD or -MMD for deps tracking these days, so make -M / -MM refer to
-MD / -MMD instead of the other way round.
llvm-svn: 199067
Various attribute flavours are supported in C++98. Make it clear that this
compatibility warning relates specifically to C++11-style generalized
attributes.
llvm-svn: 199053
This patch more cleanly seperates the concepts of Preferred Alignment
and Required Alignment. Most notable that changes to Required Alignment
do *not* impact preferred alignment until late in struct layout. This
is observable when using pragma pack and non-virtual bases and the use
of tail padding when laying them out.
Test cases included.
llvm-svn: 198988
rules: instead of requiring flexible array members to be POD, require them to
be trivially-destructible. This seems to be the only constraint that actually
matters here (and even then, it's questionable whether this matters).
llvm-svn: 198983
The presence of a VBPtr suppresses the presence of zero sized
sub-objects in the non-virtual portion of the object in the context of
determining if two base objects need alias-avoidance padding placed
between them.
Test cases included.
llvm-svn: 198975
...by synthesizing their body to be "return self->_prop;", with an extra
nudge to RetainCountChecker to still treat the value as +0 if we have no
other information.
This doesn't handle weak properties, but that's mostly correct anyway,
since they can go to nil at any time. This also doesn't apply to properties
whose implementations we can't see, since they may not be backed by an
ivar at all. And finally, this doesn't handle properties of C++ class type,
because we can't invoke the copy constructor. (Sema has actually done this
work already, but the AST it synthesizes is one the analyzer doesn't quite
handle -- it has an rvalue DeclRefExpr.)
Modeling setters is likely to be more difficult (since it requires
handling strong/copy), but not impossible.
<rdar://problem/11956898>
llvm-svn: 198953
which may belong to unrelated classes. It was
primarily intended for miuse of @selector expression.
But warning is too noisy and will be issued when
an actual @selector is used. // rdar://15740134
llvm-svn: 198952
With this change tok::code_completion is finally handled exclusively as a
special token kind like other tokens that need special treatment.
All callers have been updated to use the specific token consumption methods and
the parser has a clear idea the current token isn't special by the time
ConsumeToken() gets called, so this has been unreachable for some time.
ConsumeAnyToken() behaviour is unchanged and will continue to support
unexpected code completion as part of the special token path.
This survived an amount of fuzzing and validation, but please ping the list if
you hit a code path that previously relied on the old unexpected handler and
now asserts.
llvm-svn: 198942
Based on recent discussions, attempt to provide a clearer distinction between
MicrosoftMode and MicrosoftExt. This still doesn't feel perfect but gives a
better idea which is which.
Also update the CPlusPlus11 description which got missed in r171367.
C++0x is dead, long live C++0x!
llvm-svn: 198936
Before:
SomeMap[std::pair(aaaaaaaaaaaa, bbbbbbbbbbbbbbb)]
.insert(ccccccccccccccccccccccc);
After:
SomeMap[std::pair(aaaaaaaaaaaa, bbbbbbbbbbbbbbb)].insert(
ccccccccccccccccccccccc);
This seems to be about 3:1 more common in Google and Chromium style and I found
only a handful of instances inside the LLVM codebase.
llvm-svn: 198924
__declspec(align), when applied to bitfields affects their perferred
alignment instead of their required alignment. We don't know why.
Also, #pragma pack(n) turns packing *off* if n is greater than the
pointer size. This is now observable because of the impact of
declspec(align) on bitfields.
llvm-svn: 198907
property has the naming convention that implies 'ownership'.
2) improve on diagnostic and make it property specific.
3) fix the line number in the case of default property
synthesis. // rdar://15757510
llvm-svn: 198905
just valid C++11 =)
Original commit message:
PR18427: Use an appropriately-aligned buffer in APValue, to avoid a crash on
SPARC, where uint64_t apparently requires higher alignment than void*.
llvm-svn: 198903
The MS abi lays out *all* non-virtual bases with leading vfptrs before
laying out non-virutal bases without vfptrs. This guarantees that the
primary base is laid out first. r198818 fixed RecordLayoutBuilder to
produce compatiable layouts. This patch fixes CGRecordLayoutBuilder to
be able to consume those layouts and produce meaningful output without
tripping any asserts about assumed incoming layout.
A test case is included that shows CGRecordLayoutBuilder in fact
produces output in the compatiable order.
llvm-svn: 198900
Preserves the setting of -fretain-comments-from-system-headers when
building/saving/loading module files. This allows code completion to pick up
documentation comments from system modules.
llvm-svn: 198890
Chandler Carruth