attributes. In cases where the merged declaration is fully equivalent to the
two original ones, some of the code was getLVForDecl was duplicated.
Cases that are still handled in getLVForDecl are things like
__private_extern__ int N;
int N;
For which we cannot produce a single merged decl with all the information.
llvm-svn: 167703
would have diagnosed this at instantiation time anyway, if only we
didn't hang on all of these test cases. Fixes <rdar://problem/12629723>
llvm-svn: 167651
Do this by making the mangleNumber(APSInt) overload look like
the int64_t version. (The latter should probably just delegate
to the former).
Test from Evgeny Eltsin!
llvm-svn: 167599
Spent longer than reasonable looking for a nice way to test this & decided to
give up for now. Open to suggestions/requests. Richard Smith suggested adding
something to ASTMatchers but it wasn't readily apparent how to test this with
that.
llvm-svn: 167507
doesn't include padding up to the alignment of the record, take this
as a cue that the alignment of the record should (conservatively) be
set to 1. This is similar to other the other cues we use to determine
that the record has a lower alignment, e.g., that the
externally-supplied layout places fields at lower offsets than we
would. Fixes <rdar://problem/12582052>; test case in LLDB.
llvm-svn: 166824
only actually get the answer right if there was only a single
anonymous struct/union at that level. This is part of
<rdar://problem/11904570>; the test will go into LLDB itself.
llvm-svn: 166781
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
llvm-svn: 166508
XML comment for declarations which pretty-prints
declaration. I had to XFAIL one test annotate-comments.cpp.
This test is currently unmaintainable as written.
Dmitri G., can you see what we can do about this test.
We should change this test such that adding a new tag does not wreck
havoc to the test.
llvm-svn: 166130
Because PNaCl bitcode must be target-independent, it uses some
different bitcode representations from other targets (e.g. byval and
sret for structures). This means that without additional type
information, it cannot meet some native ABI requirements for some
targets (e.g. passing structures containing unions by value on
x86-64). To allow generation of code which uses the correct native
ABIs, we also support triples such as x86_64-nacl, which uses
target-dependent IR (as opposed to le32-nacl, which uses byval and
sret).
To allow interoperation between the two types of code, this patch adds
a calling convention attribute to be used in code compiled with the
target-dependent triple, which will generate code using the le32-style
bitcode. This calling convention does not need to be explicitly
supported in the backend because it determines bitcode representation
rather than native conventions (the backend just needs to undersand
how to handle byval and sret for the Native Client OS).
This patch implements __attribute__((pnaclcall)) to generate calls in
bitcode according to the le32 bitcode conventions, an attribute which
is accepted by any Native Client target, but issues a warning
otherwise.
llvm-svn: 166065
Currently, Objective-C does not support class properties, even though it
allows calling class methods with dot syntax.
No intended functionality change; purely optimization.
llvm-svn: 165716
methods looking for documentation on a particular base
class inherited by any method that overrides the base class.
In case of redeclaration, as when objc method is defined
in the implementation, it also looks up for documentation
in class/class extension being redeclared.
llvm-svn: 165643
Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.
llvm-svn: 165628
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
AAPCS ABI Section 7.1.4 [1] specifies that va_list
should be defined as struct __va_list { void *__ap;};
And in C++, it is defined in namespace std.
[1] http://infocenter.arm.com/help/topic
/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
Patch by Weiming Zhao.
llvm-svn: 165609
ASTContext to the ObjCMethodDecl, and have the more generic
ASTContext::getOverriddenMethods() use the ObjCMethodDecl::getOverriddenMethods()
function.
llvm-svn: 165518
whether that function/method already has a body (loaded from some
other AST file), as introduced in r165137. Delay this check until
after the redeclaration chains have been wired up.
While I'm here, make the loading of method bodies lazy.
llvm-svn: 165513
of the initializer is valid before using it.
Fixes rdar://12455002&12449015 where local variables of objc objects in ARC mode
were not annotated because of the ImplicitValueInitExpr initializer having invalid
source range, resulting in the SourceRange of the VarDecl having invalid end location.
llvm-svn: 165456
GCC has always supported this on PowerPC and 4.8 supports it on all platforms,
so it's a good idea to expose it in clang too. LLVM supports this on all targets.
llvm-svn: 165362
The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to
choose a single parent for each object. In the main (only?) cases in
which the AST forms a DAG, it protects from multiple traversal by using
OpaqueValueExprs. Previously, ParentMap would just unconditionally look
through all OpaqueValueExprs when building its map.
In order to make this behavior better for the analyzer's diagnostics,
ParentMap was changed to not set a statement's parent if there already
was one in the map. However, ParentMap is supposed to allow updating
existing mappings by calling addStmt once again. This change makes the
"transparency" of OpaqueValueExprs explicit, and disables it when it
is not desired, rather than checking the current contents of the map.
This new code seems like a big change, but it should actually have
essentially the same performance as before. Only OpaqueValueExprs and
their users (PseudoObjectExpr and BinaryConditionalOperator) will
have any different behavior.
There should be no user-visible functionality change, though a test
has been added for the current behavior of BinaryConditionalOperator
source locations and accompanying Xcode arrows (which are not so great...).
llvm-svn: 165355
* nullptr used to be mapped to ERROR, now mapped to nullptr
* integral was missing
* expressions now have their own error message, so they won't reach
this. Map them to ERROR.
Note that clang usually crashes before emitting this diagnostic anyway
(see PR13984), so this change alone doesn't have an observable effect.
It makes the code more correct though.
llvm-svn: 165095
This matches what's done in ItaniumMangle and makes it a bit easier
to implement mangling for more expressions. Also use the slightly nicer
"not yet implemented" error message from there.
No functionality change (except for the different error message).
llvm-svn: 165093
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
llvm-svn: 164656
deprecation attribute ('deprecated', 'availability' or 'unavailable').
This warning is under a separate flag, -Wdocumentation-deprecated-sync, so it
can be turned off easily while leaving other -Wdocumentation warnings on.
llvm-svn: 164467
FunctionDecl that we are importing the FunctionProtoType for, in which case we'll have
infinite recursion when importing.
Initially create a FunctionProtoType with null ExceptionSpecDecl/ExceptionSpecTemplate and
update the type in ASTNodeImporter::VisitFunctionDecl after the FunctionDecl has been created.
llvm-svn: 164450
definition info; it needs to be there because the mangler needs to
access it before we're finished defining the lambda class.
PR12808.
llvm-svn: 164186
bytes of the buffer and not the size of the string, otherwise we
may overwrite the buffer if there is a mismatch between the size
of the string and the CharByteWidth, and assertions are disabled.
The bug where this could occur was fixed in r163931.
Related to rdar://12069503
llvm-svn: 163939
should be fine to use it without further explanations in the attached
paragraph, so the warning about empty paragraph was turned off for it.
llvm-svn: 163836
analysis registers a command, it becomes a "known" command for the lexer, since
it has an ID. Having this freedom of choice to register a command is a good
thing since BriefParser does not need this.
But the parser should still invoke the correct semantic analysis method
(actOnUnknownCommand) in this case.
llvm-svn: 163646
load in the IndirectField declarations as well.
Field designators in initializer lists depend on traversing the fields
decl chain to find the indirect fields.
Fixes rdar://12239321
llvm-svn: 163552
Now we have a list of all commands. This is a good thing in itself, but it
also enables us to easily implement typo correction for command names.
With this change we have objects that contain information about each command,
so it makes sense to resolve command name just once during lexing (currently we
store command names as strings and do a linear search every time some property
value is needed). Thus comment token and AST nodes were changed to contain a
command ID -- index into a tables of builtin and registered commands. Unknown
commands are registered during parsing and thus are also uniformly assigned an
ID. Using an ID instead of a StringRef is also a nice memory optimization
since ID is a small integer that fits into a common bitfield in Comment class.
This change implies that to get any information about a command (even a command
name) we need a CommandTraits object to resolve the command ID to CommandInfo*.
Currently a fresh temporary CommandTraits object is created whenever it is
needed since it does not have any state. But with this change it has state --
new commands can be registered, so a CommandTraits object was added to
ASTContext.
Also, in libclang CXComment has to be expanded to include a CXTranslationUnit
so that all functions working on comment AST nodes can get a CommandTraits
object. This breaks binary compatibility of CXComment APIs.
Now clang_FullComment_getAsXML(CXTranslationUnit TU, CXComment CXC) doesn't
need TU parameter anymore, so it was removed. This is a source-incompatible
change for this C API.
llvm-svn: 163540
unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.
Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).
llvm-svn: 163369
type is an unqualified objc pointer in arc. Treat it just
as being treated in c++98. This fixes a bogus vararg warning
with -std=c++11. //rdar://12229679
llvm-svn: 163236
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
__objc_yes/__objc_no to (BOOL)1/(BOOL)0 when
BOOL is declared; otherwise it resorts to
default of 'signed char'. This is important to
selecting the correct Numeric API numberWithBool:
Can't have a clang test for this. Will checkin and
executable llvm test. // rdar://12156616
llvm-svn: 162922
CheckLValueConstantExpression.
Richard pointed out that using the address of a TLS variable is ok in a
core C++11 constant expression, as long as it isn't part of the eventual
result of constant expression evaluation. Having the check in
CheckLValueConstantExpression accomplishes this.
llvm-svn: 162850
This makes Clang produce an error for code such as:
__thread int x;
int *p = &x;
The lvalue of a thread-local variable cannot be evaluated at compile
time.
llvm-svn: 162835
We still need to translate the string, but this at least gets us one step
closer to using the more general EmitAsmStmt() codegen function. No functional
change intended.
llvm-svn: 162785
Rafael Espindola