Semantically, a dynamic property must always be dispatched in case it gets replaced at runtime, and an @NSManaged property may not have static accessors at all. Use ordinary access to the computed property accessors in materializeForSet when a property is dynamic or ObjC-originated. More rdar://problem/18706056.
There's still a problem--we try to vtable-dispatch materializeForSet, which is redundant for native classes, but impossible for imported ObjC classes. We should suppress this, but trying to make materializeForSet "final" breaks subclassing if the property is overridden.
Swift SVN r24882
Another fix for rdar://problem/18706056. This should make @NSManaged properties work fine with @objc protocols, but I expect us to still be broken with native protocols.
Swift SVN r24862
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
a non-native owner. This is required by Slice, which
will use an ObjC immutable array object as the owner
as long as all the elements are contiguous.
As part of this, I decided it was best to encode the
native requirement in the accessor names. This makes
some of these accessors really long; we can revisit this
if we productize this feature.
Note that pinning addressors still require a native
owner, since pinning as a feature is specific to swift
refcounting.
Swift SVN r24420
Permit non-Ordinary accesses on references to functions,
with the semantics of devirtualizing the call if the
function is a class member. This is important for
constructing direct call to addressors from synthesized
materializeForSet accessors: for one, it's more
performant, and for another, addressors do not currently
appear in v-tables.
Synthesize trivial accessors for addressed class members.
We weren't doing this at all before, and I'm still not
sure we're doing it right in all cases. This is a mess.
Assorted other fixes. The new addressor kinds seem
to work now.
Swift SVN r24393
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
use a thin function type.
We still need thin-function-to-RawPointer conversions
for generic code, but that's fixable with some sort of
partial_apply_thin_recoverable instruction.
Swift SVN r24364
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
if-let statements (also while and var, of course) that include multiple bindings
and where clauses.
SILGen support still remains, it currently just asserts on the new constructs.
Swift SVN r24239
optional callback; retrofit existing implementations.
There's a lot of unpleasant traffic in raw pointers here
which I'm going to try to clean up.
Swift SVN r24123
