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
in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433
llvm-svn: 168825
constructor/assignment operator with a const-qualified parameter type. The
prior method for determining this incorrectly used overload resolution.
llvm-svn: 168775
allocated using the allocator associated with an ASTContext.
Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to
avoid a potential memory leak.
rdar://12761275
llvm-svn: 168771
It brought bunch of (possibly false) warnings.
llvm/unittests/VMCore/PassManagerTest.cpp:60:22: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleNDNM::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:86:22: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleNDM2::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:106:21: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleDNM::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:217:16: warning: variable 'initcount' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int LPass::initcount=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:218:16: warning: variable 'fincount' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int LPass::fincount=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:259:16: warning: variable 'inited' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int BPass::inited=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:260:16: warning: variable 'fin' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int BPass::fin=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:283:24: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char OnTheFlyTest::ID=0;
^
8 warnings generated.
llvm-svn: 168549
"clang -cc1 -fsyntax-only" on the preprocessed output of
#define M extern int a;
#define M2 M M
#define M4 M2 M2
#define M8 M4 M4
#define M16 M8 M8
#define M32 M16 M16
#define M64 M32 M32
#define M128 M64 M64
#define M256 M128 M128
#define M512 M256 M256
#define M1024 M512 M512
#define M2048 M1024 M1024
#define M4096 M2048 M2048
#define M8192 M4096 M4096
#define M16384 M8192 M8192
M16384
goes from 2.994s to 1.416s. GCC is at 0.022s, so we still have a long way to go.
llvm-svn: 168519
and defined within the current instantiation, but which are not part of the
current instantiation. Previously, it would look at bases which could be
specialized separately from the current template.
llvm-svn: 168477
GCC 4.7 reuses stack slots fairly aggressively, which exposes more temporary
lifetime bugs.
No new test, this was caught by the existing CodeGenCXX/mangle-ms-templates.cpp.
llvm-svn: 168124
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
non-trivial if they would not call a move operation, even if they would in fact
call a trivial copy operation. A proper fix is to follow, but this small
directed fix is intended for porting to the 3.2 release branch.
llvm-svn: 167920
This corrects the mangling and linkage of classes (& their member functions) in
cases like this:
struct foo {
struct {
void func() { ... }
} x;
};
we were accidentally giving this nested unnamed struct 'no' linkage where it
should've had the linkage of the outer class. The mangling was incorrecty too,
mangling as TU-wide unnamed type mangling of $_X rather than class-scoped
mangling of UtX_.
This also fixes -Wunused-member-function which would incorrectly diagnose
'func' as unused due to it having no linkage & thus appearing to be TU-local
when in fact it might be correctly used in another TU.
Similar mangling should be applied to function local classes in similar cases
but I've deferred that for a subsequent patch.
Review/discussion by Richard Smith, John McCall, & especially Eli Friedman.
llvm-svn: 167906
Integer literal mangling does not actually depend on exact type of the literal.
This will simplify calling mangleIntegerLiteral when literal type is not known,
for example, when sizes or offsets are mangled as integer literals.
Also, call mangleNumber instead of directly printing mangled values of 0/1, to
avoid this knowledge from being in multiple places.
Patch from Evgeny Eltsin!
llvm-svn: 167878
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
not be set for implicit instantiations, remove the FIXME. This should be the
last bit for PR13634. The actual fix happened in r162238.
Motivation: it might be misleading to mark implicit instantiations as
Decl::isImplicit = true. Because then, in order to be consistent, we should
mark all instantiated members as implicit. But the user did actually type the
declaration for the member, but the compiler played with it a little bit.
llvm-svn: 162488
"castAs<...>->doSomething()". The analyzer was flagging these
as potential null dereferences, which is technically true. The
invariants appear to be that these casts should never fail, so
let's use castAs<> instead and avoid a runtime check.
llvm-svn: 162468
name. This should reduce the amount of warning false positives about bad HTML
in comments when the comment author intended to put a reference to a template.
This change will also enable us parse the comment as intended in these cases.
Fixes part 1 of PR13374.
llvm-svn: 162407
to overwrite objects that might have been allocated into the type's
tail padding. This patch is missing some potential optimizations where
the destination is provably a complete object, but it's necessary for
correctness.
Patch by Jonathan Sauer.
llvm-svn: 162254
Add a flag PrintingPolicy::DontRecurseInDeclContext to provide "terse" output
from DeclPrinter. The motivation is to use DeclPrinter to print declarations
in user-friendly format, without overwhelming user with inner detail of the
declaration being printed.
Also add many tests for DeclPrinter. There are quite a few things that we
print incorrectly: search for WRONG in DeclPrinterTest.cpp -- and these tests
check our output against incorrect output, so that we can fix/refactor/rewrite
the DeclPrinter later.
llvm-svn: 162245
and remove ASTContext reference (which was frequently bound to a dereferenced
null pointer) from the recursive lump of printPretty functions. In so doing,
fix (at least) one case where we intended to use the 'dump' mode, but that
failed because a null ASTContext reference had been passed in.
llvm-svn: 162011
This is the other half of C++11 [class.cdtor]p4 (the destructor side
was added in r161915). This also fixes an issue with post-call checks
where the 'this' value was already being cleaned out of the state, thus
being omitted from a reconstructed CXXConstructorCall.
llvm-svn: 161981
The reason for the recent fallout for "attaching comments to any redeclaration"
change are two false assumptions:
(1) a RawComment is attached to a single decl (not true for 'typedef struct X *Y'
where we want the comment to be attached to both X and Y);
(2) the whole redeclaration chain has only a single comment (obviously false, the
user can put a separate comment for each redeclaration).
To fix (1) I revert the part of the recent change where a 'Decl*' member was
introduced to RawComment. Now ASTContext has a separate DenseMap for mapping
'Decl*' to 'FullComment*'.
To fix (2) I just removed the test with this assumption. We might not parse
every comment in redecl chain if we already parsed at least one.
llvm-svn: 161878
'templated' declaration for a function or class template to refer to
the function or class template itself, to which the documentation will
be attached. Fixes PR13593.
llvm-svn: 161762
Not only look for the comment near the declaration itself, but also walk the
redeclaration chain: the previous declaration might have had a documentation
comment.
llvm-svn: 161722
This also provides isConst/Volatile/Restrict on FunctionTypes to coalesce
the implementation with other callers (& update those other callers).
Patch contributed by Sam Panzer (panzer@google.com).
llvm-svn: 161647
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...
There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.
Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.
Review by Sean Silva and Richard Smith.
llvm-svn: 161501
update implementation to match. An elidable, non-trivial constructor call is a
side-effect under this definition, but wasn't under the old one, because we are
not required to evaluate it even though it may have an effect.
Also rationalize checking for volatile reads: just look for lvalue-to-rvalue
conversions on volatile glvalues, and ignore whether a DeclRefExpr etc is for
a volatile variable.
llvm-svn: 161393
was mistakenly classifying dynamic_casts which might throw as having no side
effects.
Switch it from a visitor to a switch, so it is kept up-to-date as future Expr
nodes are added. Move it from ExprConstant.cpp to Expr.cpp, since it's not
really related to constant expression evaluation.
Since we use HasSideEffect to determine whether to emit an unused global with
internal linkage, this has the effect of suppressing emission of globals in
some cases.
I've left many of the Objective-C cases conservatively assuming that the
expression has side-effects. I'll leave it to someone with better knowledge
of Objective-C than mine to improve them.
llvm-svn: 161388
Rafael Espindola