This gets rid of a bunch of random InvalidDecl bools in sema, changing
us to use the following approach:
1. When analyzing a declspec or declarator, if an error is found, we
set a bit in Declarator saying that it is invalid.
2. Once the Decl is created by sema, we immediately set the isInvalid
bit on it from what is in the declarator. From this point on, sema
consistently looks at and sets the bit on the decl.
This gives a very clear separation of concerns and simplifies a bunch
of code. In addition to this, this patch makes these changes:
1. it renames DeclSpec::getInvalidType() -> isInvalidType().
2. various "merge" functions no longer return bools: they just set the
invalid bit on the dest decl if invalid.
3. The ActOnTypedefDeclarator/ActOnFunctionDeclarator/ActOnVariableDeclarator
methods now set invalid on the decl returned instead of returning an
invalid bit byref.
4. In SemaType, refering to a typedef that was invalid now propagates the
bit into the resultant type. Stuff declared with the invalid typedef
will now be marked invalid.
5. Various methods like CheckVariableDeclaration now return void and set the
invalid bit on the decl they check.
There are a few minor changes to tests with this, but the only major bad
result is test/SemaCXX/constructor-recovery.cpp. I'll take a look at this
next.
llvm-svn: 70020
parameters in a functiondecl, even if the decl is invalid and has a confusing
Declarator. On the testcase, we now emit one beautiful diagnostic:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*)
^
GCC 4.0 produces:
t.c:2: error: syntax error before ‘f’
t.c: In function ‘f’:
t.c:2: error: parameter name omitted
and GCC 4.2:
t.c:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘f’
llvm-svn: 70016
typedef void foo(void);
We get a typedef for a functiontypeproto with no arguments, not
one with one argument and type void. This means the code being
removed in SemaDecl is dead.
llvm-svn: 70013
types.
- I broke this in the switch to representing interfaces with opaque
types.
- <rdar://problem/6822660> clang crashes on subscript of interface in
32-bit mode
llvm-svn: 70009
to the checker yet, but essentially it allows a user to specify that an
Objective-C method or C function increments the reference count of a passed
object.
llvm-svn: 70005
up to the checker yet, but essentially it allows a user to specify that an
Objective-C method or C function returns an owned an Objective-C object.
llvm-svn: 70001
pools, combined). The methods in the global method pool are lazily
loaded from an on-disk hash table when Sema looks into its version of
the hash tables.
llvm-svn: 69989
- Fix summary lookup for class methods to now use the (optional)
ObjCInterfaceDecl associated with a message expression. This removes a
long-standing FIXME.
- Partial fix for <rdar://problem/6062730> by stop tracking objects that
are passed to [NSObject performSelector]. These methods are often used
for delegates, which the analyzer doesn't reason about well yet.
llvm-svn: 69982
- Otherwise, we will end up with stray .dSYM files which don't get
lipo'ed or removed.
- Ideally we would run dsymutil on the result, but we don't have the
infrastructure for that yet. Note that gcc doesn't handle this case
either.
- <rdar://problem/6809621> [driver] clang leaves .dSYM files lying
around in tmp.
llvm-svn: 69951
Several changes here:
1. We change Type::isIncompleteType to realize that forward declared
interfaces are incomplete. This eliminate special case code for this
from the sizeof path, and starts us rejecting P[4] when P is a pointer
to an incomplete interface.
2. Explicitly reject P[4] when P points to an interface in non-fragile ABI
mode.
3. Switch the sizeof(interface) diagnostic back to an error instead of a
warning in non-fragile abi mode.
llvm-svn: 69943
SEL, Class, Protocol, CFConstantString, and
__objcFastEnumerationState. With this, we can now run the Objective-C
methods and properties PCH tests.
llvm-svn: 69932
extend the number of objects tracked by the retain/release checker by assuming
that all class and instance methods should follow Cocoa object "getter" and
"alloc/new" conventions.
llvm-svn: 69908
This enables class recognition to work with PCH. I believe this means we can remove Sema::ObjCInterfaceDecls and it's usage within Sema::LookupName(). Will investigate.
llvm-svn: 69891
- As with malloc and friends, this is important where the return type
on a 64-bit platform would otherwise end up discarding the upper
32-bits.
llvm-svn: 69874
Rework the shadow struct that is layed out for Objective-C classes.
- Superclasses are now always laid out in their shadow structure at
the first field.
- Prior to this, the entire class heirarchy was flattened into a
single structure which meant that alignment, padding, and bitfields
were incorrect (the ASTRecordLayout was correct however, which
meant our debug info didn't coincide with ivar offsets, for
example).
- This is still very suboptimal (for example, ivar are looked up
recursively, but I believe the ivar layout itself is now at least
close to correct.
- <rdar://problem/6773388> error: objc[29823]: layout bitmap sliding
backwards
llvm-svn: 69811
start of the declspec. The fixit still goes there, and we underline
the declspec. This helps when the start of the declspec came from a
macro that expanded from a system header. For example, we now produce:
t.c:2:8: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
static x;
~~~~~~ ^
llvm-svn: 69777
- Superclasses are now always laid out their shadow structure at the
first field.
- Prior to this, the entire class heirarchy was flattened into a
single structure which meant that alignment, padding, and bitfields
weren't packed correctly (the ASTRecordLayout was correct however,
which meant our debug info didn't coincide with ivar offsets, for
example).
- This is still very suboptimal, but I believe the ivar layout itself
is now at least close to correct.
- <rdar://problem/6773388> error: objc[29823]: layout bitmap sliding
backwards
llvm-svn: 69771
by marking the predefines buffer as a system header. The problem
with stdint is that it was getting problems like this:
/Volumes/Projects/cvs/llvm/Debug/lib/clang/1.0/include/stdint.h:43:9: warning: 'long long' is an extension when C99 mode is not enabled
typedef __INT64_TYPE__ int64_t;
^
<built-in>:73:29: note: instantiated from:
#define __INT64_TYPE__ long long
^
We correctly silence warnings in system headers, but only if the
spelling location of the token came from the system header. This is
designed so that if you use a system macro in your code that you don't
get punished for its definition. This is all cool except that the
predefines buffer wasn't considered a system header.
llvm-svn: 69770
for scoping to match C99 even when in C89 mode. This patch fixes this
(eliminating a "redefinition of thisKey" error), and also prevents non-sensical
diagnostics in -pedantic mode like this:
t.m:7:8: warning: variable declaration in for loop is a C99-specific feature
for (id thisKey in keys) ;
^
llvm-svn: 69760
extern. Previously we would warn about it and ignore the attribute.
This is incorrect, it should be handled as a c89 "extern inline"
function. Many thanks to Matthieu Castet for pointing this out and
beating me over the head until I got it.
PR3988: extern inline function are not externally visible
llvm-svn: 69756
When the StoreManager doesn't reason well about pointer-arithmetic, propagate
the non-nullness constraint on a pointer value when performing pointer
arithmetic uisng ++/--.
llvm-svn: 69741
mark exactly the blocks which have references that are "live through".
This fixes a rejects valid:
rdar://6808730 - [sema] [blocks] block rejected at global scope
llvm-svn: 69738
identifiers from a precompiled header.
This patch changes the primary name lookup method for entities within
a precompiled header. Previously, we would load all of the names of
declarations at translation unit scope into a large DenseMap (inside
the TranslationUnitDecl's DeclContext), and then perform a special
"last resort" lookup into this DeclContext when we knew there was a
PCH file (see Sema::LookupName). Now, when we see an identifier named
for the first time, we load all of the declarations with that name
that are visible from the translation unit into the IdentifierInfo's
chain of declarations. Thus, the explicit "look into the translation
unit's DeclContext" code is gone, and Sema effectively uses the same
IdentifierInfo-based name lookup mechanism whether we are using a PCH
file or not.
This approach should help PCH scale with the size of the input program
rather than the size of the PCH file. The "Hello, World!" application
with Carbon.h as a PCH file now loads 20% of the identifiers in the
PCH file rather than 85% of the identifiers.
90% of the 20% of identifiers loaded are actually loaded when we
deserialize the preprocessor state. The next step is to make the
preprocessor load macros lazily, which should drastically reduce the
number of types, declarations, and identifiers loaded for "Hello,
World".
llvm-svn: 69737
tentative definitions off to the ASTConsumer at the end of the
translation unit.
Eliminate CodeGen's internal tracking of tentative definitions, and
instead hook into ASTConsumer::CompleteTentativeDefinition. Also,
tweak the definition-deferal logic for C++, where there are no
tentative definitions.
Fixes <rdar://problem/6808352>, and will make it much easier for
precompiled headers to cope with tentative definitions in the future.
llvm-svn: 69681
addRecordToClass.
- Among other things, this fixes a crash when applying sizeof to an
interface with synthesized ivars, although things still aren't
"correct" here.
llvm-svn: 69675
minor accepts-invalid regressions, but we weren't really rejecting them for
the right reason. We really need a more general solution to detect all the
cases of the promotion of arrays with a register storage class.
llvm-svn: 69586
support it. I don't know what evaluation method we use for complex
arithmetic, so I don't know whether/if we should warn about use of
CX_LIMITED_RANGE.
This concludes my planned hacking on STDC pragmas, flame away :)
llvm-svn: 69556
Chris Lattner