unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
We were neglecting to include initializers and accessors for vars and subscripts, and we were mingling instance and class methods, causing the ObjC runtime to associate the wrong extended type information with methods. Fixes <rdar://problem/17791953>.
Swift SVN r20513
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
Some tools expect the encoding string to always be there (like KVO).
By using an empty string, this becomes valid while still not exposing
details of the ivar's layout. We can decide later if that would be a
good thing to do.
<rdar://problem/17203246>
Swift SVN r19851
Instead of hacking together inaccurate metadata only for object-typed properties, make an effort to produce accurate metadata for all types of properties, and accurately capture the "copy", "dynamic", and "weak" semantics of some properties. This is necessary for Core Data to accurately synthesize property accessors for non-object properties; currently it will generate bogus object accessors over properties with non-object type. <rdar://problem/17373368>
This isn't fully accurate, since Clang hides property type encoding behind a 'getObjCEncodingForPropertyDecl' that only accepts an ObjCPropertyDecl. With some refactoring, it should be possible to expose this.
Swift SVN r19567
Somewhere along the line, @objc inference started accepting class properties, but IRGen never got the memo, so we emitted metadata for the property and its accessor methods as if it were an instance property. Fixes <rdar://problem/17523205>.
Swift SVN r19489
We still don't want to try to lay out non-fixed fields in an ObjC class after the first one, even if we don't want to complain about all of them. Oops.
Swift SVN r18798
I checked with David Smith and he says it's been working for him, and we won't find the edge cases till more users hammer on it. ObjC-derived classes however still need some significant runtime interop work.
While we're here, make the 'unimplemented' error message less crashy by just skipping layout of non-fixed fields we can't lay out in ObjC classes yet.
Swift SVN r18797
Don't use spare bits on platforms that use ObjC tagged pointers when an enum payload involves a class-constrained existential, archetype, or ObjC-defined class type. If a payload is of a Swift-defined class type, we can still assume it's a real pointer and use its spare bits. Add an @unsafe_no_objc_tagged_pointer attribute that can be applied to protocols to denote that existentials bounded by that protocol can use spare bits; this is necessary to preserve the layout of bridged Array and Dictionary types, which should not be bound to tagged pointer types in practice (fingers crossed). Fixes <rdar://problem/16270219>.
Swift SVN r18781
dynamicCastClass assumes that the destination type is a
Swift class type.
dynamicCastObjCClass assumes that the destination type is
an ObjC class type (represented as ObjC metadata, not type
metadata).
dynamicCastUnknownClass assumes only that the destination
type is some kind of class.
Swift SVN r18776
and alignment for the purposes of deallocation.
If a class contains a method named __getInstanceSizeAndAlignMask,
and it takes no arguments and returns a pair of words, call
that method directly in order to get the size and alignment
mask instead of trusting the class's formal size and alignment.
This is not a replacement for a proper language solution for
custom allocation, but it'll suffice to fix some immediate
problems with HeapBufferStorage.
If we decide we like this approach, we should really raise
the deallocating destructor up to SIL.
rdar://16979846
Swift SVN r18485
If we officially register our classes with the ObjC runtime, we can't get away with generic class instances sharing a runtime name or a metaclass anymore, so pack the metaclass and rodata templates into the generic metadata template and add codegen to the fill function to wire up the references at instantiation time. Since we don't have a runtime mangler yet, create a stupid unique name for classes by tacking on the pointer value.
Swift SVN r17882
This exposes some inconsistencies with the ClassTypeInfo, which is still shared among all instances of the generic class. We produce suboptimal code for specialized class instances, but we don't crash anymore on <rdar://problem/16104390>.
Swift SVN r16949
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
We can't know whether a mixed-heritage class has a non-pointer isa, so use object_getClass to get its isa pointer. Fixes <rdar://problem/16656489>.
Swift SVN r16549
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
Replace HeapTypeInfo::hasSwiftRefcount with a "getSwiftRefcounting" method, returning an enum indicating whether a heap object has native/ObjC/block/unknown refcounting semantics. Use _Block_copy and _Block_release for block refcounting.
Swift SVN r16041
Centralize the logic for figuring out what name to use for a class or
protocol in the Objective-C runtime. When the flag is enabled (it's
still disabled by default), use mangled names for all Swift-defined
classes, including those that are @objc. Note that the naming is
determined in the AST, because we're also going to use this logic when
printing an Objective-C header for Clang's consumption. The mangled
names will always start with _Tt, so they're easy to recognize and
demangle in various tools or, eventually, in the Objective-C runtime.
The new test (test/IRGen/objc_mangling.sil) is the only test of this
behavior at the moment. The other test changes are due to the
centralized logic tweaking the names of internal constants (_DATA_*,
_CATEGORY_*, etc.).
This is the majority of <rdar://problem/15506580>.
Swift SVN r15588
If an extension introduces an @objc protocol conformance using existing methods that are already @objc, then we shouldn't emit @objc thunks for them again, and indeed, we can't for native ObjC classes. Fixes <rdar://problem/16330856>.
Swift SVN r15087
accessors.
Optimize these accessors by making them check for
BoundGenericXType instead of BoundGenericType and dyn_cast'ing
the Decl. (The latter used to be necessary before we split
BoundGenericType.)
Swift SVN r15037
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
1. Implement parser and sema support for our subscript syntax proposal in
protocols. Now you have to use subscript(..) { get } or {get set} to
indicate what you want. I suspect that the syntax will evolve, but at
least we can express what we need now.
2. Change the representation of SubscriptDecls in protocols to make
(empty) funcdecls for the getter and setter. This guarantees that
every subscript has at least a getter.
Swift SVN r12555
