| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
should now support all of the C++98 types, and all of the C++0x types
Clang supports.
llvm-svn: 130079
|
| |
|
|
|
|
|
|
| |
'__is_literal' type trait for GCC compatibility. At least one relased
version if libstdc++ uses this name for the trait despite it not being
documented anywhere.
llvm-svn: 130078
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operators in C++ record declarations.
This patch starts off by updating a bunch of the standard citations to
refer to the draft 0x standard so that the semantics intended for move
varianst is clear. Where necessary these are duplicated so they'll be
available in doxygen.
It adds bit fields to keep track of the state for the move constructs,
and updates all the code necessary to track this state (I think) as
members are declared for a class. It also wires the state into the
various trait-like accessors in the AST's API, and tests that the type
trait expressions now behave correctly in the presence of move
constructors and move assignment operators.
This isn't complete yet due to these glaring FIXMEs:
1) No synthesis of implicit move constructors or assignment operators.
2) I don't think we correctly enforce the new logic for both copy and
move trivial checks: that the *selected* copy/move
constructor/operator is trivial. Currently this requires *all* of them
to be trivial.
3) Some of the trait logic needs to be folded into the fine-grained
trivial bits to more closely match the wording of the standard. For
example, many of the places we currently set a bit to track POD-ness
could be removed by querying other more fine grained traits on
demand.
llvm-svn: 130076
|
| |
|
|
|
|
|
|
|
|
|
| |
language options, and warn when reading an AST with a different value
for the bit.
There doesn't appear to be a good way to test this (commenting out
similar other language options doesn't break anything) but if folks have
suggestions on tests I'm happy to add them.
llvm-svn: 130071
|
| |
|
|
| |
llvm-svn: 130068
|
| |
|
|
|
|
| |
from dgregor.
llvm-svn: 130066
|
| |
|
|
|
|
|
| |
a 'deprecated' selector in the diagnostics for the
selector. // rdar://9309223
llvm-svn: 130062
|
| |
|
|
| |
llvm-svn: 130058
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a few APIs on the AST to bundle up the standard-based
logic so that programmatic clients have access to exactly the same
behavior.
There is only one serious FIXME here: checking for non-trivial move
constructors and move assignment operators. Those bits need to be added
to the declaration and accessors provided.
This implementation should be enough for the uses of __is_trivial in
libstdc++ 4.6's C++98 library implementation.
Ideas for more thorough test cases or any edge cases missing would be
appreciated. =D
llvm-svn: 130057
|
| |
|
|
|
|
| |
sorted in order to prepare for adding some new ones.
llvm-svn: 130056
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
matches GCC behavior which libstdc++ uses to limit #warning-based
messages about deprecation.
The machinery involves threading this through a new '-fdeprecated-macro'
flag for CC1. The flag defaults to "on", similarly to -Wdeprecated. We
turn the flag off in the driver when the warning is turned off (modulo
matching some GCC bugs). We record this as a language option, and key
the preprocessor on the option when introducing the define.
A separate flag rather than a '-D' flag allows us to properly represent
the difference between C and C++ builds (only C++ receives the define),
and it allows the specific behavior of following -Wdeprecated without
potentially impacting the set of user-provided macro flags.
llvm-svn: 130055
|
| |
|
|
| |
llvm-svn: 130054
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wwrite-strings. First and foremost, once the positive form of the flag
was passed, it could never be disabled by passing -Wno-write-strings.
Also, the diagnostic engine couldn't in turn use -Wwrite-strings to
control diagnostics (as GCC does) because it was essentially hijacked to
drive the language semantics.
Fix this by giving CC1 a clean '-fconst-strings' flag to enable
const-qualified strings in C and ObjC compilations. Corresponding
'-fno-const-strings' is also added. Then the driver is taught to
introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings'
dominates.
This entire flag is basically GCC-bug-compatibility driven, so we also
match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm
open to changing this though as it seems insane.
llvm-svn: 130051
|
| |
|
|
| |
llvm-svn: 130045
|
| |
|
|
| |
llvm-svn: 130043
|
| |
|
|
| |
llvm-svn: 130042
|
| |
|
|
|
|
| |
method definition.
llvm-svn: 130037
|
| |
|
|
|
|
| |
expression. Thanks goes to Eli Friedman!
llvm-svn: 130036
|
| |
|
|
|
|
| |
the c99 preprocessor. Patch by Jonathan Sauer!
llvm-svn: 130031
|
| |
|
|
|
|
| |
-flate-template-parsing mode.
llvm-svn: 130030
|
| |
|
|
|
|
| |
Fixes rdar://9202628 & http://llvm.org/PR9564.
llvm-svn: 130024
|
| |
|
|
|
|
|
|
| |
new templates that need to be instantiated and vice-versa. Iterate
until we've instantiated all required templates and defined all
required vtables. Fixed PR9325 / <rdar://problem/9055177>.
llvm-svn: 130023
|
| |
|
|
|
|
|
|
|
| |
function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup.
Using this flag is necessary for compatibility with Microsoft template code.
This also provides some parsing speed improvement.
llvm-svn: 130022
|
| |
|
|
|
|
|
|
|
|
|
| |
ObjC NeXt runtime where method pointer registered in
metadata belongs to an unrelated method. Ast part of this fix,
I turned at @end missing warning (for class
implementations) into an error as we can never
be sure that meta-data being generated is correct.
// rdar://9072317
llvm-svn: 130019
|
| |
|
|
|
|
| |
warning in Microsoft mode.
llvm-svn: 130010
|
| |
|
|
| |
llvm-svn: 130009
|
| |
|
|
|
|
|
|
|
| |
cases that demonstrates exactly why this does indeed apply in 0x mode.
If isPOD is currently broken in 0x mode, we should fix that directly
rather than papering over it here.
llvm-svn: 130007
|
| |
|
|
|
|
| |
Fixes assertion later on. rdar://9122937 & http://llvm.org/PR9459
llvm-svn: 130006
|
| |
|
|
| |
llvm-svn: 130003
|
| |
|
|
|
|
| |
functionality intended.
llvm-svn: 130002
|
| |
|
|
|
|
| |
variables to CharUnits. No change in functionality intended.
llvm-svn: 130001
|
| |
|
|
|
|
|
|
| |
true.
Fixes an assertion later on, rdar://9122862 & http://llvm.org/PR9460.
llvm-svn: 130000
|
| |
|
|
|
|
| |
change in functionality intended.
llvm-svn: 129999
|
| |
|
|
|
|
| |
EmitTypeForVarWithBlocksAttr(). No change in functionality intended.
llvm-svn: 129998
|
| |
|
|
|
|
| |
functionality intended.
llvm-svn: 129996
|
| |
|
|
| |
llvm-svn: 129987
|
| |
|
|
|
|
| |
warnings I introduced lately.
llvm-svn: 129986
|
| |
|
|
|
|
| |
to a warning in Microsoft mode.
llvm-svn: 129985
|
| |
|
|
|
|
|
|
| |
double data[20000000] = { [19999999] = 1 };
Don't serialize the filler multiple times.
llvm-svn: 129983
|
| |
|
|
| |
llvm-svn: 129967
|
| |
|
|
|
|
|
|
|
| |
compile time) and .gcda emission (at runtime). --coverage enables both.
This does not yet add the profile_rt library to the link step if -fprofile-arcs
is enabled when linking.
llvm-svn: 129956
|
| |
|
|
| |
llvm-svn: 129954
|
| |
|
|
| |
llvm-svn: 129951
|
| |
|
|
|
|
|
|
| |
system header
inside DiagnosticIDs::getDiagnosticLevel.
llvm-svn: 129950
|
| |
|
|
|
|
| |
but the condition is the same either way.
llvm-svn: 129948
|
| |
|
|
|
|
|
|
|
|
|
| |
instance, in the following code, 'case ' will be suggested before the '1:'
switch (x) {
1: return 0;
default: return 1;
}
llvm-svn: 129943
|
| |
|
|
|
|
| |
can't be represented in the environment define.
llvm-svn: 129939
|
| |
|
|
|
|
|
|
| |
designated initializers,
avoiding to create separate Exprs for each one.
llvm-svn: 129933
|
| |
|
|
| |
llvm-svn: 129929
|
| |
|
|
|
|
|
|
| |
the first step towards a standalone Clang tool infrastructure.
The plan is to make it easy to build command line tools that run over
the AST of source files in a project outside of the build system.
llvm-svn: 129924
|