applied to ObjCMethodDecls, not just parameters. This allows one to specific
side-effects on the receiver of a message expression. No checker support yet.
llvm-svn: 70505
appear between the return type and the selector. This is a separate code path
from regular attribute processing, as we only want to (a) accept only a specific
set of attributes in this place and (b) want to distinguish to clients the
context in which an attribute was added to an ObjCMethodDecl.
Currently, the attribute 'objc_ownership_returns' is the only attribute that
uses this new feature. Shortly I will add a warning for 'objc_ownership_returns'
to be placed at the end of a method declaration.
llvm-svn: 70504
"aligned" attribute. Previously, we were skipping over these
attributes when we jumped directly to the canonical type. Now,
ASTContext::getTypeInfo walks through typedefs and other
"non-canonical" types manually, looking for "aligned" attributes on
typedefs.
As part of this change, I moved the GNU-specific logic (such as
determining the alignment of void or of a function pointer) out of the
expression evaluator and into ASTContext::getTypeInfo.
llvm-svn: 70497
This fixes <rdar://problem/6839489> 10A345: Clang does not warm about mismatched returns (void return from a bool function)
Will implement -Wreturn-type, -Wno-return-type in another commit.
llvm-svn: 70492
compatible with VC++ and GCC. The codegen/mangling angle hasn't
been fully ironed out yet. Note that we accept int128_t even in
32-bit mode, unlike gcc.
llvm-svn: 70464
type and argument types are missing, and let return type deduction
happen before we give errors for returning from a noreturn block.
Radar 6441502
llvm-svn: 70413
1. In a struct field redefinition, don't mark the struct erroneous. The
field is erroneous, but the struct is otherwise well formed.
2. Don't emit diagnostics about functions that are known to be broken already.
Either fix is sufficient to silence the second diagnostic in the example,
but the combination is better :)
llvm-svn: 70371
1. All all variants of -Wformat*, make them imply -Wformat. GCC warns
if you use -Wformatfoo without -Wformat. We just make one imply the
other.
2. Make -Wformat-nonliteral default to off, like gcc. It is an incredible
nuisance.
3. Accept but currently ignore -Wformat-extra-args.
llvm-svn: 70362
line when using a PCH that were not provided when building the PCH
file. If those names were used as identifiers somewhere in the PCH
file, reject the PCH file.
llvm-svn: 70321
PCH file and the predefines buffer used when including the PCH
file. We (explicitly) detect conflicting macro definitions (rejecting
the PCH file) and about missing macro definitions (they'll be
automatically pulled from the PCH file anyway).
We're missing some checking to make sure that new macro definitions
won't have any impact on the PCH file itself (e.g., #define'ing an
identifier that the PCH file used).
llvm-svn: 70316
"function designator".
(This causes a minor glitch in the
diagnostics for C++ member pointers, but we weren't printing the
right diagnostic there anyway.)
llvm-svn: 70307
mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.
As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.
llvm-svn: 70292
scheme to be more useful.
The new scheme introduces a set of categories that should be more
readable, and also reflects what we want to consider as an extension
more accurately. Specifically, it makes the "what is a keyword"
determination accurately reflect whether the keyword is a GNU or
Microsoft extension.
I also introduced separate flags for keyword aliases; this is useful
because the classification of the aliases is mostly unrelated to the
classification of the original keyword.
This patch treats anything that's in the implementation
namespace (prefixed with "__", or "_X" where "X" is any upper-case
letter) as a keyword without marking it as an extension. This is
consistent with the standards in that an implementation is allowed to define
arbitrary extensions in the implementation namespace without violating
the standard. This gets rid of all the nasty "extension used" warnings
for stuff like __attribute__ in -pedantic mode. We still warn for
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we
could add additional information to the keyword table.
This also removes processing for the unused "Boolean" language option;
such an extension isn't supported on any other C implementation, so I
don't see any point to adding it.
The changes to test/CodeGen/inline.c are required because previously, we
weren't actually disabling the "inline" keyword in -std=c89 mode.
I'll remove Boolean and NoExtensions from LangOptions in a follow-up
commit.
llvm-svn: 70281
as 'objc_ownership_cfretain' except that the method acts like a CFRetain instead
of a [... retain] (important in GC modes). Checker support is wired up, but
currently only for Objective-C message expressions (not function calls).
llvm-svn: 70218
before r69391: typedef redefinition is an error by default, but if
*either* the old or new definition are from a system header, we silence
it.
llvm-svn: 70177
offsetof correctly in the presence of anonymous structs/unions.
This could definitely use some cleanup, but I don't really want to mess
with the anonymous union/struct code.
llvm-svn: 70156
Before we emitted:
$ clang t.c -S -m64
llvm: error: Unsupported asm: input constraint with a matching output constraint of incompatible type!
Now we produce:
$ clang t.c -S -m64
t.c:5:40: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'int'
asm volatile("foo " : "=a" (a) :"0" (b));
~~~ ~^~
llvm-svn: 70142
Overall, I'm not particularly happy with the current situation regarding
constant expression diagnostics, but I plan to improve it at some point.
llvm-svn: 70089
VerifyIntegerConstantExpression instead of isIntegerConstantExpr.
This makes it ext-warn but tolerate things that fold to a constant
but that are not valid i-c-e's.
There must be a bug in the i-c-e computation though, because it
doesn't catch this case even with pedantic.
This also switches the later code to use EvaluateAsInt which is
simpler and handles everything that evaluate does.
llvm-svn: 70081
always return a non-null QualType + error bit. This fixes a bunch of
cases that didn't check for null result (and could thus crash) and eliminates
some crappy code scattered throughout sema.
This also improves the diagnostics in the recursive struct case to eliminate
a bogus second error. It also cleans up the case added to function.c by forming
a proper function type even though the declarator is erroneous, allowing the
parameter to be added to the function. Before:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*P)
^
t.c:4:3: error: use of undeclared identifier 'P'
P+1;
^
After:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*P)
^
llvm-svn: 70023
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
in a function-like macro body. This has the added bonus of moving some
function-like macro specific code out of the object-like macro codepath.
llvm-svn: 69530
- The confusing IRgen bitfield interface is partly to blame here;
fixing the functional error for now, cleanups to the interface to
follow.
llvm-svn: 69503
statements don't end up in the LabelMap so we don't have a quick way
to filter them. We could add state to Sema (a "has vla" and "has
jump" bit) to try to filter this out, but that would be sort of gross
and I'm not convinced it is the best way. Thoughts welcome.
llvm-svn: 69476
specific bad case instead of on the switch. Putting it on the
switch means you don't know what case is the problem. For
example:
scope-check.c:54:3: error: illegal switch case into protected scope
case 2:
^
scope-check.c:53:9: note: jump bypasses initialization of variable length array
int a[x];
^
llvm-svn: 69462
as decimal, even if it starts with 0. Also, since things like 0x1 are
completely illegal, don't even bother using numericliteralparser for them.
llvm-svn: 69454
produce better diagnostics, and be more correct in ObjC cases (fixing
rdar://6803963).
An example is that we now diagnose:
int test1(int x) {
goto L;
int a[x];
int b[x];
L:
return sizeof a;
}
with:
scope-check.c:15:3: error: illegal goto into protected scope
goto L;
^
scope-check.c:17:7: note: scope created by variable length array
int b[x];
^
scope-check.c:16:7: note: scope created by variable length array
int a[x];
^
instead of just saying "invalid jump". An ObjC example is:
void test1() {
goto L;
@try {
L: ;
} @finally {
}
}
t.m:6:3: error: illegal goto into protected scope
goto L;
^
t.m:7:3: note: scope created by @try block
@try {
^
There are a whole ton of fixme's for stuff to do, but I believe that this
is a monotonic improvement over what we had.
llvm-svn: 69437
AST context's __builtin_va_list type will be set when the PCH file is
loaded. This fixes the crash when CodeGen'ing a va_arg expression
pulled in from a PCH file.
llvm-svn: 69421
Highlights: PP::isNextPPTokenLParen() no longer eats the (
when present. We now simplify slightly the logic parsing
macro arguments. We now handle PR3937 and other related cases
correctly.
llvm-svn: 69411
lazy PCH deserialization. Propagate that argument wherever it needs to
be. No functionality change, except that I've tightened up a few PCH
tests in preparation.
llvm-svn: 69406
1. We had logic in sema to decide whether or not to emit the error
based on manually checking whether in a system header file.
2. we were allowing redefinitions of typedefs in class scope in C++
if in header file.
3. there was no way to force typedef redefinitions to be accepted
by the C compiler, which annoys me when stripping linemarkers out
of .i files.
The fix is to split the C++ class typedef redefinition path from the
C path, and change the C path to be a warning that normally maps to
error. This causes it to properly be ignored in system headers,
etc. and gives us a way to control it. Passing
-Wtypedef-redefinition now turns the error into a warning.
One behavior change is that we now diagnose cases where you redefine
a typedef in your .c file that was defined in a header file. This
seems like reasonable behavior, and the diagnostic now indicates that
it can be controlled with -Wtypedef-redefinition.
llvm-svn: 69391
1) Accidentally used delete [] on an array of statements that was allocated with ASTContext's allocator
2) Deserialization of names with multiple declarations (e.g., a struct and a function) used the wrong mangling constant, causing it to view declaration IDs as Decl*s.
403.gcc builds and links properly.
llvm-svn: 69390
Anders Carlsson