Note that this also fixes a bug that affects non-template code, where we
were not treating out-of-line static data members are "file-scope" variables,
and therefore not checking their initializers.
llvm-svn: 77002
and __has_trivial_constructor builtin pseudo-functions and
additionally implements __has_trivial_copy and __has_trivial_assign,
from John McCall!
llvm-svn: 76916
- Move Sema::ObjCQualifiedIdTypesAreCompatible(), Sema::QualifiedIdConformsQualifiedId(), and a couple helper functions to ASTContext.
- Change ASTContext::canAssignObjCInterfaces() to use ASTContext:: ObjCQualifiedIdTypesAreCompatible().
- Tweak several test cases to accommodate the new/improved type checking.
llvm-svn: 76830
an interface/category with its implementation (if one exists).
- Introduce ObjCInterfaceDecl::get/setImplementation() and ObjCCategoryDecl::get/setImplementation() that use the above methods.
- Add a compiler error for when a category is reimplemented.
llvm-svn: 76508
- Remove Sema::CheckPointeeTypesForAssignment(), a temporary API I added to ease migration to ObjCObjectPointerType. Convert Sema::CheckAssignmentConstraints() to no longer depend on the temporary API.
- Sema::ConvertDeclSpecToType(): Replace a couple FIXME's with an important comment/example.
- Sema::GetTypeForDeclarator(): Get the protocol's from the interface, NOT the declspec (to support the following C typedef idiom: "typedef C<P> T; T *obj").
- Sema::ObjCQualifiedIdTypesAreCompatible(): Removed some dead code.
- ASTContext::getObjCEncodingForTypeImpl(): Some minor cleanups.
llvm-svn: 76443
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
This removes the static data/methods on ObjCObjectPointerType while preserving the nice API (no need to fiddle with ASTContext:-).
This patch also adds Type::isObjCBuiltinType().
This should be the last fairly large patch related to recrafting the ObjC type system. The follow-on patches should be fairly small.
llvm-svn: 75808
I don't love the name, however it simplifies the code and is a worthwhile change. If/when we come up with a better name, we can do a search/replace.
llvm-svn: 75650
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
FILE type, rather than using name lookup to find FILE within the
translation unit. Within precompiled headers, FILE is treated as yet
another "special type" (like __builtin_va_list).
This change should provide a performance improvement (not verified),
since the lookup into the translation unit declaration
forces the (otherwise unneeded) construction of a large hash table.
More importantly, with precompiled headers, the construction
of that table requires deserializing most of the top-level
declarations from the precompiled header, which are then unused.
Fixes PR 4509.
llvm-svn: 74911
declaration in the AST.
The new ASTContext::getCommentForDecl function searches for a comment
that is attached to the given declaration, and returns that comment,
which may be composed of several comment blocks.
Comments are always available in an AST. However, to avoid harming
performance, we don't actually parse the comments. Rather, we keep the
source ranges of all of the comments within a large, sorted vector,
then lazily extract comments via a binary search in that vector only
when needed (which never occurs in a "normal" compile).
Comments are written to a precompiled header/AST file as a blob of
source ranges. That blob is only lazily loaded when one requests a
comment for a declaration (this never occurs in a "normal" compile).
The indexer testbed now supports comment extraction. When the
-point-at location points to a declaration with a Doxygen-style
comment, the indexer testbed prints the associated comment
block(s). See test/Index/comments.c for an example.
Some notes:
- We don't actually attempt to parse the comment blocks themselves,
beyond identifying them as Doxygen comment blocks to associate them
with a declaration.
- We won't find comment blocks that aren't adjacent to the
declaration, because we start our search based on the location of
the declaration.
- We don't go through the necessary hops to find, for example,
whether some redeclaration of a declaration has comments when our
current declaration does not. Similarly, we don't attempt to
associate a \param Foo marker in a function body comment with the
parameter named Foo (although that is certainly possible).
- Verification of my "no performance impact" claims is still "to be
done".
llvm-svn: 74704
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
This is simple enough, but then I thought it would be nice to make PrintingPolicy
get a LangOptions so that various things can key off "bool" and "C++" independently.
This spiraled out of control. There are many fixme's, but I think things are slightly
better than they were before.
One thing that can be improved: CFG should probably have an ASTContext pointer in it,
which would simplify its clients.
llvm-svn: 74493
Add a type (ObjCObjectPointerType) and remove a type (ObjCQualifiedIdType).
This large/tedious patch is just a first step. Next step is to remove ObjCQualifiedInterfaceType. After that, I will remove the magic TypedefType for 'id' (installed by Sema). This work will enable various simplifications throughout clang (when dealing with ObjC types).
No functionality change.
llvm-svn: 73649
preprocessor and initialize it early in clang-cc. This
ensures that __has_builtin works in all modes, not just
when ASTContext is around.
llvm-svn: 73319
hack which introduces some strange inconsistencies in compatibility
for block pointers.
Note that unlike an earlier revision proposed on cfe-commits, this patch
still allows declaring block pointers without a prototype.
llvm-svn: 73041
in merge_types. It is incomplete. We probably want to issue
a warning if user attempts to change the attribute from __weak to
__strong or vice-vera. It also assumes that a __weak/__strong
attribute can not be specified with other (currently one) type
attriute.
llvm-svn: 72711
properties at the moment:
1. It allows stuff like "__strong id x; __weak id x;".
2. For constructs like "__strong id x; id x;", subsequent references to
x lose the objc_gc attribute.
3. This incorrectly allows merges involving the address_space attribute.
4. Constructs like "id x; /* some code using x */ __weak id x;" don't
apply the objc_gc attribute consistently to all uses of x.
The first three can probably be fixed relatively easily; the fourth
would be extremely difficult to fix.
llvm-svn: 72683
printing logic to help customize the output. For now, we use this
rather than a special flag to suppress the "struct" when printing
"struct X" and to print the Boolean type as "bool" in C++ but "_Bool"
in C.
llvm-svn: 72590
template. The injected-class-name is either a type or a template,
depending on whether a '<' follows it. As a type, the
injected-class-name's template argument list contains its template
parameters in declaration order.
As part of this, add logic for canonicalizing declarations, and be
sure to canonicalize declarations used in template names and template
arguments.
A TagType is dependent if the declaration it references is dependent.
I'm not happy about the rather complicated protocol needed to use
ASTContext::getTemplateSpecializationType.
llvm-svn: 71408
compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
- Also, we now report the size info for an empty class like gcc (as
the offset of the start, not as 0, 0).
- Add a few more test cases we were mishandling before (padding bit
field at end of struct, for example).
llvm-svn: 70938
- This implements gcc style Objective-C interface layout (I
think). Currently it is always off, there is no functionality
change unless this is passed.
For the curious, the deal is that gcc lays out the fields of a
subclass as if they were part of the superclass. That is, the
subclass fields immediately follow the super class fields instead
of being padded to the alignment of the superclass structure.
- Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
llvm-gcc uses it in 32-bit only, for reasons which aren't clear
yet. We probably want to switch to matching gcc, once this makes it
through testing... my hope is that we can also fix llvm-gcc in
order to maintain compatibility between the compilers.
llvm-svn: 70827
via CollectObjCIvars.
- In places where we need them, we should have the implementation and
access the properties through it.
This is a fairly substantial functionality change:
1. @encode no longer encodes synthesized ivars, ever.
2. The ivar layout bitmap no longer encodes information for
synthesized ivars in superclasses. Well, actually I had already
broken that, but it is intentional now.
We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.
Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.
I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.
llvm-svn: 70822
struct.
- We still need to do more lookup than necessary because ivars don't
live in a reasonable DeclContext.
- The only remaining client of the interface shadow struct is the
ivar layout bitmap.
llvm-svn: 70756
- These routines should now be independent of the Sema state.
- This is nearly zero functionality change, the distinction only
matters in the non-fragile ABI, and the consumers that care about
this distinction should be using getASTObjCImplementationLayout.
llvm-svn: 70692
- The difference from getASTObjCInterfaceLayout is that the computes
the layout including synthesized ivars.
- No functionality change, they currently both compute the same thing
-- whether that includes synthesized ivars or not depends on when
they get called!!!
llvm-svn: 70690
"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
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
SEL, Class, Protocol, CFConstantString, and
__objcFastEnumerationState. With this, we can now run the Objective-C
methods and properties PCH tests.
llvm-svn: 69932
methods, class methods, and property implementations) and instead
place all of these entities into the DeclContext.
This eliminates more linear walks when looking for class or instance
methods and should make PCH (de-)serialization of ObjCDecls trivial
(and lazy).
llvm-svn: 69849
PCH files now contain complete information about builtins, including
any declarations that have been synthesized as part of building the
PCH file. When using a PCH file, we do not initialize builtins at all;
when needed, they'll be found in the PCH file.
This optimization translations into a 9% speedup for "Hello, World!"
with Carbon.h as a prefix header and roughly a 5% speedup for 403.gcc
with its prefix header. We're also reading less of the PCH file for
"Hello, World!":
*** PCH Statistics:
286/20693 types read (1.382110%)
1630/59230 declarations read (2.751984%)
764/44914 identifiers read (1.701029%)
1/32954 statements read (0.003035%)
5/6187 macros read (0.080815%)
down from
*** PCH Statistics:
411/20693 types read (1.986179%)
2553/59230 declarations read (4.310316%)
1093/44646 identifiers read (2.448148%)
1/32954 statements read (0.003035%)
21/6187 macros read (0.339421%)
llvm-svn: 69815
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
- 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
@implementation that closes a @class delcaration.
- I don't know how to make a test case for this, but this strengthens
the invariants that hold internally. The functionality change here
is the edit to SemaDeclObjC.cpp.
llvm-svn: 69728
This fixes <rdar://problem/6782722> XCDataTipsManager.m registers, observes notifications in class methods.
The radar above is the result of clang typing 'self' in a class method as 'Class', which results in some spurious warnings (GCC types 'self' in a class method as 'id').
I considered changing the type of 'self' to 'id' (to conform to GCC), however this resulted in *many* test cases breaking. In addition, I really prefer a more strongly typed 'self'.
All in all, this is the least obtrusive fix I could find for removing the spurious warnings (though we do loose some valid warnings).
llvm-svn: 69041
de-serialization of abstract syntax trees.
PCH support serializes the contents of the abstract syntax tree (AST)
to a bitstream. When the PCH file is read, declarations are serialized
as-needed. For example, a declaration of a variable "x" will be
deserialized only when its VarDecl can be found by a client, e.g.,
based on name lookup for "x" or traversing the entire contents of the
owner of "x".
This commit provides the framework for serialization and (lazy)
deserialization, along with support for variable and typedef
declarations (along with several kinds of types). More
declarations/types, along with important auxiliary structures (source
manager, preprocessor, etc.), will follow.
llvm-svn: 68732
types. It is no longer needed now that the code generator
re-lays-out interfaces if they are defines after being laid out
from a forward decl.
llvm-svn: 68194
In a case like:
@class foo;
foo *P;
addRecordToClass was making an empty shadow struct for the foo interface and
completing it. Later when an:
@interface foo
...
@endif
foo *Q;
was seen, ASTContext::addRecordToClass would think that foo was already laid
out and not lay out the definition. This fixes it to create a forward declared
struct the first time around, then complete it when the definition is seen.
Note that this causes two tests to regress, because something is trying to get
the size of the forward declared structs returned by this. Previously, this
would end up getting a size of zero but now it properly dies. I'm not sure
what the right solution is for this, so I xfailed the tests.
Fariborz, please take a look at this. The testcase in rdar://6676794 now gets
farther, but dies later because the objc ivar is not assigned a field number.
As an aside, I really don't like the fact that the objc front-end is creating
shadow C structs for ObjC types. This seems like an implementation detail of
the code generator that could be fixed by better factoring of the extant code.
llvm-svn: 68106
within nested-name-specifiers, e.g., for the "apply" in
typename MetaFun::template apply<T1, T2>::type
At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.
llvm-svn: 68081
representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").
One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as
std::(vector<int>)
we represent it as
(std::vector)<int>
which more closely follows the C++ grammar.
Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.
llvm-svn: 68074
instantiation for C++ typename-specifiers such as
typename T::type
The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,
typename T::template apply<U, V>
Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.
Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples.
llvm-svn: 67875
uniqued representation that should both save some memory and make it
far easier to properly build canonical types for types involving
dependent nested-name-specifiers, e.g., "typename T::Nested::type".
This approach will greatly simplify the representation of
CXXScopeSpec. That'll be next.
llvm-svn: 67799
isObjCObjectPointerType to work with qualified types. Adjust test for
changes.
If the SemaExpr changes are wrong or break existing code, feel free to
delete the "ExprTy.addConst();" line and revert my changes to
test/Sema/block-literal.c.
llvm-svn: 67489
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
llvm-svn: 67265
such as replacing 'T' in vector<T>. There are a few aspects to this:
- Extend TemplateArgument to allow arbitrary expressions (an
Expr*), and switch ClassTemplateSpecializationType to store
TemplateArguments rather than it's own type-or-expression
representation.
- ClassTemplateSpecializationType can now store dependent types. In
that case, the canonical type is another
ClassTemplateSpecializationType (with default template arguments
expanded) rather than a declaration (we don't build Decls for
dependent types).
- Split ActOnClassTemplateId into ActOnClassTemplateId (called from
the parser) and CheckClassTemplateId (called from
ActOnClassTemplateId and InstantiateType). They're smart enough to
handle dependent types, now.
llvm-svn: 66509
Mike Stump