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
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
variables in ObjC's Next runtime mode. Next runtime also implicitly applies
'used' attribute on some of its meta-data. This results in two
'llvm.used' arrays to be generated, and one of them is renamed to
'llvm.used1'.
llvm-svn: 74008
message dispage API for all but a few messages. This is
a runtime performance improvement and there is not meant
to be a functional change.
llvm-svn: 71467
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
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
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
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
- This has pros and cons, but for now the pros seem to significantly
outway the con.
The con is that we will always need to cast in the runtime
implementation to a struct type, if we wish to access an interface
directly.
The pros are:
- Avoid the cost of generating types which are used. Most
manipulation of Objective-C objects is done through messages, and
only the implementation of a class will directly access
memory. Previously, we would convert the type even if it only
appear as a function parameter, for example.
- We don't need to worry about incomplete types, and
UpdateCompletedType for interfaces is gone.
- It becomes easier to narrow the interface to the shadow struct for
Objective-C interfaces (so it can be eliminated).
Currently the runtimes still use the CodeGenTypes machinery to
generate the LLVM structure they need via ConvertTagDecl, but this can
eventually be replaced.
llvm-svn: 69797
- For now, this means we are always doing the address computations by
hand instead of constructing a proper GEP. Right now, however, this
is less important than having fewer entry points to dealing with
Objective-C interface layout.
llvm-svn: 69787
- 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
Drop uses of GetFirstInvarInRecord, instead we lookup the ivars we
know are in the record.
- This is somewhat less efficient, but I need to detangle this code
first...
llvm-svn: 69579
- 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
- This was particularly bad since I fixed one instance of this name
and not another, meaning we got an LLVM module with the same
effective name in two different globals!
llvm-svn: 69205
- Set alignment on property lists.
- 32-bit:
o Set section on property lists.
o Fix section name for category class methods.
o Fix symbol name for property lists.
o Fix section name for class method.
o Set alignment and section on class extension structure.
o Set alignment on a number of things: instance variables, methods,
method descriptions, the symbols structure.
- 64-bit:
o Fix section flags for protocol list.
I doubt most of these were problems in practice, but it is nice to
match llvm-gcc.
llvm-svn: 69132
- Changed method names to match gcc (categories names still aren't
mangled in).
- Expose correct name for class and metadata symbols (although
-fvisibility=hidden isn't yet correct).
- Remove several things from llvm.used that didn't need to be there
(I suspect this can still be trimmed).
- Don't use asm-prefix extension for _objc_empty_{cache,vtable} (not
needed).
- Hide EH type class info with -fvisibility=hidden
- Change setGlobal[Option]Visibility to not change the visibility of
functions with internal linkage.
llvm-svn: 68510
ObjCNonFragileABITypesHelper by converting them to dynamic
getters. This fixes a crash on rdar://6757213. The others
should be converted over as well.
llvm-svn: 68445
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
Changed GenerateConstantString() to take an ObjCStringLiteral (instead of a std::string). While this isn't strictly necessary, it seems cleaner and allows us to cache to "containsNonAscii" if necessary (to avoid checking in both Sema and CodeGen).
llvm-svn: 68114
- Temporarily undef'ed __OBJC2__ in nonfragile objc abi mode
as it was forcing ivar synthesis in a certain project which clang
does not yet support.
llvm-svn: 67766
performance that the type of the returned llvm::Value for an expression
matches the converted type of the clang::Expr; mismatches will cause all
sorts of errors and silent miscompilations.
llvm-svn: 66321
Also necessary to fix:
<rdar://problem/6632061> [sema] non object types should not be allowed in @catch statements
<rdar://problem/6252237> [sema] qualified id should be disallowed in @catch statements
llvm-svn: 65964
- Still manually generates the EH code; the parts related to cleanup
need to be integrated into the cleanup stack (for proper
interaction with VLAs, etc.).
- Some differences vs gcc in corner cases; I believe our behavior is
correct but need to verify/file bugs vs gcc.
llvm-svn: 65809
- Only handles cases with @try with no @catch blocks, and there are a
number of problems with the implementation. Nevertheless, this is
good enough to handled @synchronized correctly, and some other
basic uses.
llvm-svn: 65378
which consequently caused a Seg fault. during meta-data
generation. It also addresses an issue related to
late binding of newly synthesize ivars (when we support it).
llvm-svn: 64563
- rename isObjCIdType/isObjCClassType -> isObjCIdStructType/isObjCClassStructType. The previous name didn't do what you would expect.
- add back isObjCIdType/isObjCClassType to do what you would expect. Not currently used, however many of the isObjCIdStructType/isObjCClassStructType clients could be converted over time.
- move static Sema function areComparableObjCInterfaces to ASTContext (renamed to areComparableObjCPointerTypes, since it now operates on pointer types).
llvm-svn: 64385
infrastructure to construct function type.
- For consistencty, we should probably always use this to construct
function types, but these are absolutely necessary to ensure that
we can emit calls to these functions.
llvm-svn: 63695
- Lift CGFunctionInfo creation up to callers of EmitCall.
- Move isVariadic bit out of CGFunctionInfo, take as argument to
GetFunctionType instead.
No functionality change.
llvm-svn: 63550
that every declaration lives inside a DeclContext.
Moved several things that don't have names but were ScopedDecls (and,
therefore, NamedDecls) to inherit from Decl rather than NamedDecl,
including ObjCImplementationDecl and LinkageSpecDecl. Now, we don't
store empty DeclarationNames for these things, nor do we try to insert
them into DeclContext's lookup structure.
The serialization tests are temporarily disabled. We'll re-enable them
once we've sorted out the remaining ownership/serialiazation issues
between DeclContexts and TranslationUnion, DeclGroups, etc.
llvm-svn: 62562
Anders Carlsson