template instantiation. Preserve it through PCH. Show it off to the indexer.
I'm healthily ignoring the vector type cases because we don't have a sensible
TypeLoc implementation for them anyway.
llvm-svn: 84994
- I have this crazy dream that one day someone will invent a miraculous tool so
that developers, instead of hand optimizing their source code to obscure its
intent and decrease its maleability, will instead write what they mean, and
this strange and wonderful tool -- which I imagine would be called something
fancy sounding like "an optimizing compiler" -- will make their code fast
*for* them. With all the saved time, developers could maybe even focus on
making the magic "optimizing compiler" better!!
- No intended functionality change, all though I expect the universe to mock me
for snarkiness.
llvm-svn: 84390
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
DeclaratorDecl contains a DeclaratorInfo* to keep type source info.
Subclasses of DeclaratorDecl are FieldDecl, FunctionDecl, and VarDecl.
EnumConstantDecl still inherits from ValueDecl since it has no need for DeclaratorInfo.
Decl/Sema interfaces accept a DeclaratorInfo as parameter but no DeclaratorInfo is created yet.
llvm-svn: 79392
declarations (and not function pointers). This is consistent with GCC. Accepting
this attribute on function pointers means that the attribute should be treated
as a type qualifier, which apparently is not what GCC does. We obviously can
change this later should we desire to enhance the 'malloc' attribute in this
way.
llvm-svn: 79060
attaching to Objective-C methods (which mirrors GCC's behavior) and to allow the
return type of the function to be an Objective-C pointer or Block pointer (which
GCC also accepts).
Along the way, add 'const' to some of the pointer arguments of various utility
functions...
llvm-svn: 79040
1. Passing something that isn't a string used to cause:
"argument to annotate attribute was not a string literal"
make it say "section attribute" instead.
2. Fix the location of the above message to point to the
bad argument instead of the section token.
3. Implement rdar://4341926, by diagnosing invalid section
specifiers in the frontend rather than letting them slip all
the way to the assembler (a QoI win).
An example of #3 is that we used to produce something like this:
/var/folders/n7/n7Yno9ihEm894640nJdSQU+++TI/-Tmp-//ccFPFGtT.s:2:Expected comma after segment-name
/var/folders/n7/n7Yno9ihEm894640nJdSQU+++TI/-Tmp-//ccFPFGtT.s:2:Rest of line ignored. 1st junk character valued 46 (.).
Daniel improved clang to use llvm_report_error, so now we got:
$ clang t.c -c
fatal error: error in backend: Global variable 'x' has an invalid section specifier 'sadf': mach-o section specifier
requires a segment and section separated by a comma.
with no loc info. Now we get:
$ clang t.c -fsyntax-only
t.c:4:30: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment
and section separated by a comma
int x __attribute__((section("sadf")));
^
which is nice :)
llvm-svn: 78586
This is necessary because #pragma pack and __attribute__((packed)) have different semantics. No functionality change yet, but this lays the groundwork for fixing a record layout bug.
llvm-svn: 78483
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
llvm-svn: 77510
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
This method is intended to eventually replace the individual
Type::getAsXXXType<> methods.
The motivation behind this change is twofold:
1) Reduce redundant implementations of Type::getAsXXXType() methods. Most of
them are basically copy-and-paste.
2) By centralizing the implementation of the getAs<Type> logic we can more
smoothly move over to Doug Gregor's proposed canonical type smart pointer
scheme.
Along with this patch:
a) Removed 'Type::getAsPointerType()'; now clients use getAs<PointerType>.
b) Removed 'Type::getAsBlockPointerTypE()'; now clients use getAs<BlockPointerType>.
llvm-svn: 76098
Objective-C pointers to using ObjCObjectPointerType.
Now the checking for 'attribute ((nonnull))' in Sema doesn't emit an error when
trying to apply that attribute to a parameter that is an Objective-C pointer
(this is a regression).
To prevent this regression from occuring in the future, the 'nonnull.c' test was
moved to test/SemaObjC and renamed 'nonnull.m'. I also enhanced the tests to
show that function calls involved a NULL Objective-C pointer constant does not
trigger a warning. This is consistent with GCC, but should likely be fixed.
llvm-svn: 75856
The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.
This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.
By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time.
Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.
llvm-svn: 75314
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
llvm-svn: 74506
The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
llvm-svn: 74501
cf_returns_retained. Currently this attribute can now be applied to any
Objective-C method or C function that returns a pointer or Objective-C object
type.
Modify the tablegen definition of diagnostic 'warn_attribute_wrong_decl_type' to
expect that the diagnostics infrastructure will add quotes around the attribute
name when appropriate. Alonq with this change, I modified the places where this
warning is issued to passed the attribute's IdentifierInfo* instead of having a
hard-coded C constant string.
llvm-svn: 71718
It seems dubious to me that isIntegerType() returns true for
vectors of integers, but not complex integers. This should
probably be rethought, I'll file a bugzilla.
llvm-svn: 71640
don't support. While it would be nice to support this eventually,
this form is not common at all (just seen in gcc testsuite) and
it might be better to model vector_size as a type attribute anyway.
For now just emit a nice error on it.
llvm-svn: 71633
'objc_ownership_cfretain' -> 'cf_ownership_retain'
'objc_ownership_cfrelease' -> 'cf_ownership_release'
Motivation: Core Foundation objects can be used in isolation from Objective-C,
and this forces users to reason about the separate semantics of CF objects. More
Sema support pending.
llvm-svn: 70884
return type and the selector. This is inconsistent with C functions
(where such attributes would be placed on the return type, not the the
FunctionDecl), and is inconsistent with what people are use to seeing.
llvm-svn: 70878
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
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
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
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
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
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
clients of the analyzer to designate custom assertion routines as "noreturn"
functions from the analyzer's perspective but not the compiler's.
llvm-svn: 68746
while I was at it. There are still a lot of diagnostics missing from
this code, and it isn't completely correct for anything other than x86, but
it should work correctly on x86 for valid cases.
llvm-svn: 65935
giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types.
Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.
As part of this, some types have been renamed:
TypeOfExpr -> TypeOfExprType
FunctionTypeProto -> FunctionProtoType
FunctionTypeNoProto -> FunctionNoProtoType
There shouldn't be any functionality change...
llvm-svn: 65591
1) implement parser and sema support for reading and verifying attribute(warnunusedresult).
2) rename hasLocalSideEffect to isUnusedResultAWarning, inverting the sense
of its result.
3) extend isUnusedResultAWarning to directly return the loc and range
info that should be reported to the user. Make it substantially more
precise in some cases than what was previously reported.
4) teach isUnusedResultAWarning about CallExpr to decls that are
pure/const/warnunusedresult, fixing a fixme.
5) change warn_attribute_wrong_decl_type to not pass in english strings, instead,
pass in integers and use %select.
llvm-svn: 64543
Currently only used for 128-bit integers.
Note that we can't use the fixed-width integer types for other integer
modes without other changes because glibc headers redefines (u)int*_t
and friends using the mode attribute. For example, this means that uint64_t
has to be compatible with unsigned __attribute((mode(DI))), and
uint64_t is currently defined to long long. And I have a feeling we'll
run into issues if we try to define uint64_t as something which isn't
either long or long long.
This doesn't get the alignment right in most cases, including
the 128-bit integer case; I'll file a PR shortly. The gist of the issue
is that the targets don't really expose the information necessary to
figure out the alignment outside of the target description, so there's a
non-trivial amount of work involved in getting it working right. That
said, the alignment used is conservative, so the only issue with the
current implementation is ABI compatibility.
This makes it trivial to add some sort of "bitwidth" attribute to make
arbitrary-width integers; I'll do that in a followup.
We could also use this for stuff like the following for compatibility
with gcc, but I have a feeling it would be a better idea for clang to be
consistent between C and C++ modes rather than follow gcc's example for
C mode.
struct {unsigned long long x : 33;} x;
unsigned long long a(void) {return x.x+1;}
llvm-svn: 64434
This commit adds a new attribute, "overloadable", that enables C++
function overloading in C. The attribute can only be added to function
declarations, e.g.,
int *f(int) __attribute__((overloadable));
If the "overloadable" attribute exists on a function with a given
name, *all* functions with that name (and in that scope) must have the
"overloadable" attribute. Sets of overloaded functions with the
"overloadable" attribute then follow the normal C++ rules for
overloaded functions, e.g., overloads must have different
parameter-type-lists from each other.
When calling an overloaded function in C, we follow the same
overloading rules as C++, with three extensions to the set of standard
conversions:
- A value of a given struct or union type T can be converted to the
type T. This is just the identity conversion. (In C++, this would
go through a copy constructor).
- A value of pointer type T* can be converted to a value of type U*
if T and U are compatible types. This conversion has Conversion
rank (it's considered a pointer conversion in C).
- A value of type T can be converted to a value of type U if T and U
are compatible (and are not both pointer types). This conversion
has Conversion rank (it's considered to be a new kind of
conversion unique to C, a "compatible" conversion).
Known defects (and, therefore, next steps):
1) The standard-conversion handling does not understand conversions
involving _Complex or vector extensions, so it is likely to get
these wrong. We need to add these conversions.
2) All overloadable functions with the same name will have the same
linkage name, which means we'll get a collision in the linker (if
not sooner). We'll need to mangle the names of these functions.
llvm-svn: 64336
- Changes Lookup*Name functions to return NamedDecls, instead of
Decls. Unfortunately my recent statement that it will simplify lot of
code, was not quite right, but it simplifies some...
- Makes MergeLookupResult SmallPtrSet instead of vector, following
Douglas suggestions.
- Adds %qN format for printing qualified names to Diagnostic.
- Avoids searching for using-directives in Scopes, which are not
DeclScope, during unqualified name lookup.
llvm-svn: 63739
.def file for each library. This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.
Patch by Anders Johnsen!
llvm-svn: 63111
and separates lexical name lookup from qualified name lookup. In
particular:
* Make DeclContext the central data structure for storing and
looking up declarations within existing declarations, e.g., members
of structs/unions/classes, enumerators in C++0x enums, members of
C++ namespaces, and (later) members of Objective-C
interfaces/implementations. DeclContext uses a lazily-constructed
data structure optimized for fast lookup (array for small contexts,
hash table for larger contexts).
* Implement C++ qualified name lookup in terms of lookup into
DeclContext.
* Implement C++ unqualified name lookup in terms of
qualified+unqualified name lookup (since unqualified lookup is not
purely lexical in C++!)
* Limit the use of the chains of declarations stored in
IdentifierInfo to those names declared lexically.
* Eliminate CXXFieldDecl, collapsing its behavior into
FieldDecl. (FieldDecl is now a ScopedDecl).
* Make RecordDecl into a DeclContext and eliminates its
Members/NumMembers fields (since one can just iterate through the
DeclContext to get the fields).
llvm-svn: 60878
instead of converting them to strings first. This also fixes a
bunch of minor inconsistencies in the diagnostics emitted by clang
and adds a bunch of FIXME's to DiagnosticKinds.def.
llvm-svn: 59948
with implicit quotes around them. This has a bunch of follow-on
effects and requires tweaking to a whole lot of code. This causes
a regression in two tests (xfailed) by causing it to emit things like:
Line 10: duplicate interface declaration for category 'MyClass1' ('Category1')
instead of:
Line 10: duplicate interface declaration for category 'MyClass1(Category1)'
I will fix this in a follow-up commit.
As part of this, I had to start switching stuff to use ->getDeclName() instead
of Decl::getName() for consistency. This is good, but I was planning to do this
as an independent patch. There will be several follow-on patches
to clean up some of the mess, but this patch is already too big.
llvm-svn: 59917
__builtin_prefetch code to only emit one diagnostic per builtin_prefetch.
While this has nothing to do with the rest of the patch, the code seemed
like overkill when I was updating it.
llvm-svn: 59588
- Support noreturn on function-typed variables.
- Extend isFunctionOrMethod to return true for K&R functions and
provide hasFunctionProto to check if a decl has information about
its arguments. This code needs some serious cleaning, but works.
- Add/improve test cases for noreturn and unused.
llvm-svn: 57778
is to encode the state of the #pragma pack stack as an attribute when
the structure is declared.
- Extend PackedAttr to take an alignment (in bits), and reuse for
both __attribute__((packed)) (which takes no argument, instead
packing tightly (to "minimize the memory required") and for #pragma
pack (which allows specification of the maximum alignment in
bytes). __attribute__((packed)) is just encoded as Alignment=1.
This conflates two related but different mechanisms, but it didn't
seem worth another attribute.
- I have attempted to follow the MSVC semantics as opposed to the gcc
ones, since if I understand correctly #pragma pack originated with
MSVC. The semantics are generally equivalent except when the stack
is altered during the definition of a structure; its not clear if
anyone does this in practice. See testcase if curious.
llvm-svn: 57623
anywhere near correct in terms of missing cases and missing
diagnostics, but it's good enough to handle the uses in the
Linux system headers, which are currently a constant pain for compiling
applications on Linux.
llvm-svn: 55621
- warn about nonnull being applied to functions with no pointer arguments
- continue processing argument list in the attribute when we encounter a non-pointer parameter being marked as nonnull
- when no argument list is specified, only mark pointers as nonnull. This fixes PR 2732 and radar 6188814.
llvm-svn: 55610
- Kill unnecessary #includes in .cpp files. This is an automatic
sweep so some things removed are actually used, but happen to be
included by a previous header. I tried to get rid of the obvious
examples and this was the easiest way to trim the #includes in one
fell swoop.
- We now return to regularly scheduled development.
llvm-svn: 54632
decl attributes out of the various places they can hide. This makes
us correctly reject things like this:
t.c:2:22: error: mode attribute only supported for integer and floating-point types
int **__attribute((mode(HI)))* i32;
^
because you can't make a pointer be HImode.
llvm-svn: 52876
to work list the rest of the attr handlers. Also, rename
it to HandleVectorSizeAttribute to match its attr name.
No functionality change.
llvm-svn: 52872
the single attribute they look at by reference instead of by pointer.
This is a subtle indicator that they take the specified attribute, not
a whole list of them.
This also make HandleExtVectorTypeAttribute work the same way as the rest
of the attributes, adds some comments etc. No functionality change.
llvm-svn: 52871
John McCall