This means: handling of alloc_ref [stack].
It can be configured with two new options. See Option/FrontendOptions.td.
As the [stack] attribute is not generated yet, there should be NFC.
Swift SVN r32929
dealloc_ref [destructor] is the existing behavior. It expects the
reference count to have reached zero and the isDeallocating bit to
be set.
The new [constructor] variant first drops the initial strong
reference.
This allows DI to properly free uninitialized instances in
constructors. Previously this would fail with an assertion if the
runtime was built with debugging enabled.
Progress on <rdar://problem/21991742>.
Swift SVN r31142
Core Data synthesizes Key-Value-Coding-compliant accessors for @NSManaged
properties, but Swift won't allow them to be called without predeclaring
them.
In practice, '@NSManaged' on a method is the same as 'dynamic', except
you /can't/ provide a body and overriding it won't work. This is not the
long-term model we want (see rdar://problem/20829214), but it fixes a
short-term issue with an unfortunate workaround (go through
mutableOrderedSetValueForKey(_:) and similar methods).
rdar://problem/17583057
Swift SVN r30523
SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
This commit reapplies r29266 with a conservative build fix
that disables ObjC property descriptors for @objc properties
that lack a getter. That should only be possible in SIL
files, because @objc should force accessors to be synthesized.
Arguably, Sema shouldn't be marking things implicitly @objc
in SIL files, but I'll leave that decision open for now.
Swift SVN r29272
SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
Swift SVN r29266
The last remaining case was apparently @objc generic classes, which
seem to work now.
Also nuke the IRGen/unimplemented_objc_generic_class.swift test,
this is now implemented and we have other tests that test this
functionality.
Swift SVN r29260
It looks like John and Joe already did a good part of this. The previous
patch to enable polymorphic @objc_method signatures takes us further, and
I think this patch fills in the rest.
Fixes <rdar://problem/18505295>, <rdar://problem/20700287>.
Swift SVN r29259
The last remaining case was apparently @objc generic classes, which
seem to work now.
Also nuke the IRGen/unimplemented_objc_generic_class.swift test,
this is now implemented and we have other tests that test this
functionality.
Swift SVN r29138
It looks like John and Joe already did a good part of this. The previous
patch to enable polymorphic @objc_method signatures takes us further, and
I think this patch fills in the rest.
Fixes <rdar://problem/18505295>, <rdar://problem/20700287>.
Swift SVN r29137
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
