Age | Commit message (Collapse) | Author |
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
put out the bitmap when all objects are scanned.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79947 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79316 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- This is just to normalize, these will go away soon hopefully.
Added all the missing '&&'s that have crept in. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77062 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
maps for GC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76978 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the ObjC type system rewrite).
It's unfortunate that the mangling includes the low-level structs. Nevertheless, we need this for binary compatibility with GCC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76755 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76637 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76518 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
multiple times.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76513 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76320 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in 32bit abi.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76109 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
names (rev. 75875)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75876 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75589 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Previously this would crash on recursive types, and it was also incorrectly
stripping off a level of indirection.
- I'm not 100% convinced this is all correct, but it should be a monotonic
improvment.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75582 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
XFAIL this for now until I prepare clang specific patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75575 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75504 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75473 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75400 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Previous code was based on a misunderstanding (on my part) of the type
representation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75385 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- This was a latent bug exposed by the recent objc type changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75383 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75314 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
gc'able structs in the Next runtime and adds missing
PCH info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75014 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74008 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Jean-Daniel Dupas
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73343 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73300 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73158 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
___Block_byref_id_object_dispose and ___Block_byref_id_object_copy
functions so that we can simply reuse instead of creating a new one.
Additionally, add an assert to ensure no one yet tries to align a
__block variable beyond the alignment of a pointer as the codegen is
incomplete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72974 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
position to make it consistant and to match gcc's behavior,
by placing it at the inner-most pointer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72784 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for the Next runtime.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72703 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
not runaable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72695 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72330 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Otherwise we may incorrectly miss generation of some write barriers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
interface types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72036 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72014 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
else the method will not be found by the runtime at class load time).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71904 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Otherwise we emit internal names with embedded '\01' characters,
which confuses some tools.
- Ideally all the code which wants to get a "display name" for the
given function should follow one code path, but this should be a
monotonic improvement for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71774 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
emit the correct "display name". I suspect we need more work here, see
FIXME for example.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71761 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
debug info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
only and used in class imllementations (objc2 Nonfragile ABI specific).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71571 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
objc_assign_global API when assigning to global
objective-c object pointer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70939 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70938 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70918 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
layout.
- This is much simpler / more efficient.
- This also properly computes the size in the presence of bit-fields.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70916 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70822 91177308-0d34-0410-b5e6-96231b3b80d8
|