Getters and setters don't always take self at +1, in particular @objc accessors, so we can't just take the base object as an unmanaged thing. Fixes <rdar://problem/16398756>.
Swift SVN r15372
Loosen the restrictions on open_existential_ref to also allow it to
refer to an existential metatype. When it does, open_existential_ref
returns the metatype for the opened archetype.
Swift SVN r15113
Rather than simply trapping with no output, have the initializer stubs
call into a new standard library function _unimplemented_initializer
that emits a more reasonable diagnostic, containing the name of the
class, the name of the initializer, and the file/line/column where the
class itself is defined. This finishes <rdar://problem/16156996>.
Swift SVN r15049
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
Although we don't expose their method and initializer entrypoints as @objc, generic @objc subclasses still need to inherit ObjC allocation from their superclass. A partial fix to <rdar://problem/16309189>, though there is still some IRGen fallout to chase out, causing test/IRGen/objc_subclass.swift to fail (as well as the test case from the radar).
Swift SVN r14991
When a subclass does not implement a designated initializer of its
superclass, introduce a stub initializer that simply traps. Such stubs
cannot be invoked directly using Swift syntax, but can be invoked
through the Objective-C runtime and from Objective-C code. Catch such
errors rather than allowing them to violate the memory safety of the
language.
Note that we're currently using cond_fail to trap; this will be
improved in the future,
Swift SVN r14839
Collect the identifiers for the selector pieces we parsed and use them to build a compound DeclName for the func decl. Currently this only manifests when __FUNCTION__ is used inside a selector-style function definition, where we now correctly produce the compound 'foo:bar:' name.
Swift SVN r14717
Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
The cleanup stack pointer is not reset when there are only dead cleanups in a scope, so relax this assertion to check that there are no live cleanups instead of that the cleanup handles are at the same height. Fixes <rdar://problem/16203107>.
Swift SVN r14674
Inherited initializers are now functional: one can use an inherited
initializer to construct an object of a subclass type, and we properly
handle delegation to overridden complete object or subobject
initializers as appropriate. See the executable test.
This commit also contains various fixes for the IRGen side of vtable
emission and use. Proper IRGen tests still to come.
For now, we're still performing peer delegation from a subobject
initializer to another subobject initializer, hence the SILGen hack
for identifying when we're in a complete object vs. a subobject
initializer. We'll be banning delegation from subobject initializers,
so this hack---along with the peer_method instruction---will be going
away in the near future.
Swift SVN r14571
alloc_ref_dynamic allocates an instance of a class type based on the
value in its metatype operand. Start emitting these instructions for
the allocating constructor of a complete object initializer (not yet
tested) and for the allocating constructor synthesized for an imported
Objective-C init method.
Still missing:
- IRGen still does the same thing as alloc_ref right now. That
change will follow.
- There are devirtualization opportunities when we know the value of
the metatype that would turn an alloc_ref_dynamic into an alloc_ref;
I'm not planning to do this optimization.
Swift SVN r14560
It's not forming the metatype for the protocol type (exists t: P. t).metatype, it's forming the existential of a metatype of a conforming type, exists t: P. (t.metatype).
Swift SVN r14520
Having one instruction to get the dynamic metatype of a (non-existential) value makes more sense from a generic specialization standpoint and should stave off inevitable crashers when archetype_metatypes get specialized. protocol_metatype remains separate because metatype existentials are more interesting.
Swift SVN r14499
We were wantonly applying 'upcast' to archetypes in some cases, and really, that's OK, since these instructions do the same thing (and generic specialization could turn archetype_ref_to_super into upcast). Make everyone's life easier by folding archetype_to_super into upcast. Fixes <rdar://problem/16192324>.
Swift SVN r14496
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
ExistentialMemberRefExpr, and enhance silgen to avoid unnecessary copies of protocol
and archetype bases. With this, uses of properties in protocols start to work.
Swift SVN r14270
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
The 'metatype' instruction can produce either a thick or Objective-C
metatype value for a class. Sometimes SILGen picks the "wrong" one,
and ends up converting the value directly, which is sub-optimal. Clean
this up in SILBuilder.
I didn't add a corresponding SILCombine optimization, nor did I add
this for class_metatype, because it seems unlikely that those will
occur in practice.
Swift SVN r14183
Introduce basic bridging support for class metatypes as
arguments/parameters. Note that we don't yet bridge 'self' for a class
method, which is the more interesting case; that will follow.
Swift SVN r14123
This has the nice "side effect" of making overrides of generic
functions work better, fixing the remaining type checker issues from
<rdar://problem/15836098>.
Also synthesize the types for derived RawRepresentable conformances
directly rather than going through the type checker, so we get the
interface types right.
Swift SVN r14066
Riding off of project_existential[_ref] was convenient, but the
resuls are used quite differently. Note that open_existential[_ref]
still don't print/parse reasonably yet.
Swift SVN r13878
'self' is formally a 'val', but we allocate a mutable box for it to accommodate self-rebinding by super.init, and we tried to pass the box owner and address as the closure parameters instead of the expected pass-by-value semantics. Fix it to properly handle the capture by value.
Swift SVN r13824
<rdar://problem/15967182> fixed the inference of @objc for
initializers, but our SILGen predicate deciding whether to perform
Objective-C dispatch was failing to heed the @objc bit on
constructors. Fixes <rdar://problem/16041090>.
Swift SVN r13787
When applying a function that was produced via a covariant function
conversion, strip off that covariant function conversion and introduce
a covariant (function or return) conversion outside of the
application. This allows us to perform the covariant conversion very
late, eliminating the need to produce reabstraction thunks for any
call to a DynamicSelf method.
Swift SVN r13779
Most of the complexity here is teaching SILGen how to handle closed-over direct
accesses to observing properties, since all of the getter/setter/willSet/didSet
members of the property are actually full closures when in a function body.
We generate correct but really terrible code here, since the setter captures the
willset/didset members themselves. I'm not worrying about the performance of
this construct though, functionality is what matters.
Swift SVN r13778
