Now that we have lazy metadata accessors for classes and vtable thunking, we don't have any reason to prevent concrete subclasses of generic base classes. Wire up IRGen to lazily instantiate the superclass for concrete derived classes when their metadata is accessed, using a runtime function that installs all the necessary pointers and metadata and registers the fully-initialized class with the ObjC runtime.
Swift SVN r28520
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Rather than swizzle the superclass of these bridging classes at +load time, have the compiler set their ObjC runtime base classes, using a "@_swift_native_objc_runtime_base" attribute that tells the compiler to use a different implicit base class from SwiftObject. This lets the runtime shed its last lingering +loads, and should overall be more robust, since it doesn't rely on static initialization order or deprecated ObjC runtime calls.
Swift SVN r28219
@objc protocols aren't supported with an ObjC runtime, but we still want values of AnyObject type to be word-sized. Handle this by turning the binary "needsWitnessTable" condition into a "dispatch strategy" enum, so we can recognize the condition "has no methods, so neither swift nor objc dispatch" as distinct from either swift or ObjC protocol representations. Assign this dispatch strategy when we lower AnyObject. Should be NFC for the ObjC-enabled build.
(It would also be beneficial for the ObjC-runtime-enabled version of Swift if AnyObject weren't an @objc protocol; that would mean we could give it a canonical protocol descriptor in the standard library, among other things. There are fairly deep assumptions in Sema that AnyObject is @objc, though, and it's not worth disturbing those assumptions right now.)
Reapplying with updates to the runtime unit tests.
Swift SVN r27341
@objc protocols aren't supported with an ObjC runtime, but we still want values of AnyObject type to be word-sized. Handle this by turning the binary "needsWitnessTable" condition into a "dispatch strategy" enum, so we can recognize the condition "has no methods, so neither swift nor objc dispatch" as distinct from either swift or ObjC protocol representations. Assign this dispatch strategy when we lower AnyObject. Should be NFC for the ObjC-enabled build.
(It would also be beneficial for the ObjC-runtime-enabled version of Swift if AnyObject weren't an @objc protocol; that would mean we could give it a canonical protocol descriptor in the standard library, among other things. There are fairly deep assumptions in Sema that AnyObject is @objc, though, and it's not worth disturbing those assumptions right now.)
Swift SVN r27338
This is an internal-only affordance for the numerics team to be able to work on SIMD-compatible types. For now, it can only increase alignment of fixed-layout structs and enums; dynamic layout, classes, and other obvious extensions are left to another day when we can design a proper layout control design.
Swift SVN r27323
This is necessary for correctly dealing with non-standard
ownership conventions in secondary positions, and it should
also help with non-injective type imports (like BOOL/_Bool).
But right now we aren't doing much with it.
Swift SVN r26954
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Class-constrained generics may produce a class type definition with fixed field offsets, but still requires type substitution, so we need to check if a bitcast is necessary. Fixes rdar://problem/19902523.
Swift SVN r25631
Always perform override checking based on the Swift type
signatures, rather than alternately relying on the Objective-C
selectors. This ensures that we get consistent override behavior for
@objc vs. non-@objc declarations throughout, and we separately make
sure that the Objective-C names line up.
This also allows us to inherit @objc'ness correctly (which didn't
quite work before), including inferring the Objective-C selector/name
(the actual subject of rdar://problem/18998564).
Fixes rdar://problem/18998564.
Swift SVN r25392
Previously, we were using the Objective-C names to help determine
whether a declaration is an override or not. This is broken, because
we should determine overrides based on the Swift rules for
overriding, then (later) check that the Objective-C runtime will see
the same override behavior that the Swift runtime does. Address this
problem, both by taking the Objective-C selector out of the equation
when matching overrides (except for diagnostic purposes) and by
performing better validation of the Objective-C names for the
overriding vs. overridden methods/properties.
The motivating case here (from rdar://problem/18998564) is an
Objective-C initializer:
-(instancetype)initString:(NSString *)string;
When trying to override this in a Swift subclass, one naturally
writes:
override init(string: String)
which implicitly has the selector initWithString:. We ended up in an
unfortunate place where we rejected the override (because the
selectors didn't match) with a crummy diagnostic, but omitting the
"override" would result in a different conflict with the superclass.
Now, we'll treat this as an override and complain that one needs to
rename the method by adding "@objc(initString:)" (with a Fix-It, of
course). This fixes rdar://problem/18998564, but it is not ideal: the
complete solution (covered by rdar://problem/19812955) involves
reworking the dance between override and @objc so that we compute
'override' first (ignoring @objc-ness entirely), and let the
@objc'ness of the overridden declaration both imply @objc for the
overriding declaration and implicitly fix the selector. However, such
a change is too risky right now, hence the radar clone.
Swift SVN r25243
Per the previous commit we are no longer using this. Minor save in
simplicity and maybe a bit of compilation time as well.
In the long run IRGen probably shouldn't be pulling information from the
AST at all; the SILModule should be able to tell it what types it needs
to emit information for. But this is still an improvement for now.
No functionality change (that was the previous commit).
Swift SVN r24840
Easy cut down on exported symbols. Unless a private type is referenced in
an inlineable function, there's no way to generate a reference to it
outside of the current file, except in the debugger. (That last bit is why
we can't use fully private linkage, which would keep the symbol out of the
symbol table completely.)
We should be doing this for "internal" declarations as well, but the
standard library /does/ have references to internal types in inlineable
functions, and also has tests that directly access these types.
Swift SVN r24838
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
This commit repplies r24305 with two fixes:
- It fixes the computation of spare bits for unusual
integer types to use the already-agreed-upon type
size instead of recomputing it. This fixes the
i386 stdlib build. Joe and I agreed that we should
also change the size to use the LLVM alloc size
instead of the next power of 2, but this patch
does not do that yet.
- It changes the spare bits in function types back
to the empty set. I'll be changing this in a
follow-up, but it needs to be tied to runtime
changes. This fixes the regression test failures.
Swift SVN r24324
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
Swift SVN r24305
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
This works by loading the protocols from a specially named symbol,
which is generated by the linker through the help of a linker script
that merges all of the protocol conformance blocks into one section
with its size at the start of it and points a global symbol at
the section.
We do all this because unlike MachO, section information does not
survive to be loaded into memory with ELF binaries. Instead,
the mappings that survive are 'segments', which contain one or
more sections. Information about how these relate to their original
sections is difficult, if not impossible, to obtain at runtime.
Swift SVN r23518
Specifically, a qualified lookup can now be treated as:
- a known private dependency, which does not affect downstream files
- a known non-private dependency, which may affect downstream files
- a known non-dependency
- unknown, which means the compiler will try to infer whether it's a
private dependency from the context
This commit also includes some obvious uses of the new flags, but nothing
actually too interesting yet; there shouldn't be any observable behavior
change here in normal user code.
Swift SVN r23483
This works by loading the protocols from a specially named symbol,
which is generated by the linker through the help of a linker script
that merges all of the protocol conformance blocks into one section
with its size at the start of it and points a global symbol at
the section.
We do all this because unlike MachO, section information does not
survive to be loaded into memory with ELF binaries. Instead,
the mappings that survive are 'segments', which contain one or
more sections. Information about how these relate to their original
sections is difficult, if not impossible, to obtain at runtime.
Swift SVN r23475
They don't need storage because they're empty, so we don't emit their offsets, but we still emitted references to their offset variable. Fix this by lowering ref_element_addr to an undef for empty fields.
Swift SVN r23317
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
refcounting and take advantage of it.
Also, set the Swift1 flag in classes we generate.
Also, initialize a global cache of the non-pointer-isa
mask and use that instead of object_getClass, at least
within the runtime.
Also, centralize the runtime on a _swift_getSuperclass
function and make that use a direct access while we
await word from Greg on the desired ABI requirements.
Swift SVN r21077
This avoids a crash after reporting unsupported layout in ObjC-derived classes, allowing us to cleanly report the fact it isn't supported.
Swift SVN r20777
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
