Age | Commit message (Collapse) | Author |
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72683 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72590 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
VLAs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72587 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
keep the spec out of the canonical type this time. Net effect is currently nothing, because the spec isn't checked anywhere.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72498 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
might not be the right way to do it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72490 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows me to remove some API that I don't want to carry over to ObjCObjectPointerType.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72415 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72401 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72210 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a test case
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71972 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71634 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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71408 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71405 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
improves type identity with dependent types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71152 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
until we've had a lot more discussion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71125 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
|
|
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70827 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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
invalidated by layout out the super class, we cannot cache the map
entry.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70693 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70692 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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!!!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70690 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
not supported on 32-bit targets, so we can define it to be 128-bit
aligned there too :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70464 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70145 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
context, even if we're not going to initialize the __builin_* identifiers
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70111 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SEL, Class, Protocol, CFConstantString, and
__objcFastEnumerationState. With this, we can now run the Objective-C
methods and properties PCH tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69932 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69849 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
headers. Future approaches to (de-)serializing ASTs will be based on
the PCH infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69828 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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%)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69815 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69811 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69783 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
builtins from marking IdentifierInfos as builtins. No functionality change
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69774 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69773 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69772 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
@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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69728 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when we need them -- which is exactly what some code was already
doing!
- No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69648 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
w.r.t. ASTContext::[gs]etFieldDecl, and the Field argument to
EmitObjCValueForIvar).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69639 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69578 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__string/__weak attributes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it like 'id').
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69007 91177308-0d34-0410-b5e6-96231b3b80d8
|