Add two new AST node types:
- InOutConversionExpr, which represents an '&x' expression that involves inout conversion. This will be a signal to SILGen not to introduce a writeback scope for the nested conversion call.
- LValueToPointerExpr, which represents the primitive '@lvalue T' to 'RawPointer' conversion that produces the argument to the inout conversion.
Build an InOutConversionExpr AST when an inout expression is resolved by a conversion to an BuiltinInOutAddressConvertible type.
Swift SVN r15594
Set up the disjunction system for '&x' expressions that allows them to type-check either as simple lvalue-to-inout conversions, as before, or as address conversions that go through one of the BuiltinInOut*Convertible protocols. The solution side is not yet implemented.
Swift SVN r15593
This significantly reduces the amount of overhead incurred when naively importing large external modules without referencing many of its members, which should directly improve response times in the playground. For example, the repro code attached to rdar://problem/16387393 imports Foundation but references none of its members, and with these changes its total compilation time is almost 2.5x faster.
Swift SVN r15479
assume that we know about all the optional types in play.
This isn't correct for types that can dynamically be
more optional than they appear statically, e.g. archetypes
and existentials, but it's the easiest thing to do,
and there are workarounds. I filed rdar://16374053
to handle doing the right thing.
Swift SVN r15254
Previously, we were cloning the default arguments completely, which
meant code duplication (when inheriting within a module) or simply a
failure (when inheriting across modules). Now, we reference the
default arguments where we inherited them, eliminating the
duplication. Part of <rdar://problem/16318855>.
Swift SVN r15062
Originally, I didn't want this because I felt it made
unchecked-optional too non-local --- it wasn't always
obvious that an assignment might crash because it was
implicitly dropping optionality. And that's still a
concern! But I think that overall, if we're prepared
to accept that that danger is inherent in @unchecked T?,
this is a more consistent model: @unchecked T? means
that we don't know enough about the value to say for
certain that nil is a real possibility, so we'll let
you coerce it to the underlying type, and that coercion
just might not be dynamically safe. No more special
cases for calls and member access (to the user; of
course, to the implementation these are still special cases
because of lookup and overload resolution).
Swift SVN r14796
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
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 DynamicLookupExpr expression and the DeclVisibilityKind::DynamicLookup
enum. These seem right to me, more descriptive than renaming them AnyObject.
With this, I consider 13327098 to be done.
Swift SVN r14654
This was blocked by some type-checker issues:
First, we weren't registering a constraint restriction when
tail-recursing in matchTypes (as opposed to when creating
a disjunction because multiple conversions applied). Do so,
and move the set of constraint restrictions to the constraint
system in order to make this simpler. A large amount of similar
solver state is already there, and of course solving the system
already prospectively modifies the constraint graph.
Second, only set up a potential existential conversion when
working with concrete types. Without this, we would fail to
typecheck conversions to optional protocol types, but not
optional class/struct/whatever types. It's not clear whether
whether we should ever really be considering conversions when
either of the types is non-concrete.
I believe it was the second fix which removed a need for a !
in the NewArray test case.
Swift SVN r14637
error message saying you can't do this. This resolves:
<rdar://problem/15643576> Shouldn't crash on partial application of objc method
Swift SVN r14588
Teach name lookup to find complete object initializers in its
superclass when the current class overrides all of the subobject
initializers of its direct superclass.
Clean up the implicit declaration of constructors, so we don't rely on
callers in the type checker doing the right thing.
When we refer to a constructor within the type checker, always use the
type through which the constructor was found as the result of
construction, so that we can type-check uses of inherited complete
object initializers. Fixed a problem with the creation of
OpenExistentialExprs when the base object is a metatype.
The changes to the code completion tests are an improvement: we're
generating ExprSpecific completion results when referring to the
superclass initializer with the same signature as the initializer
we're in after "super.".
Swift SVN r14551
variables
This change allows the type checker to create member references to generic
nominals with free type variables -- see tests. This is important for code
completion, for example, swift.Dictionary.#^A^#
Fixes rdar://15980316
Swift SVN r14461
Factor an IdentityExpr base class out of ParenExpr, and migrate most of the logic to see through ParenExprs to see through IdentityExprs instead. Add DotSelfExpr as a new subclass of IdentityExpr, produced by parsing 'x.self'.
Swift SVN r14381
... but obviously not when we've statically derived the existential
metatype. This isn't quite the way I'd like to prohibit these issues,
but more work on existentials and metatypes is coming up shortly.
Swift SVN r14326
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
Emit vtable entries for abstract initializers. When we're constructing
an object using an abstract initializer based on a metatype value that
is not statically derivable, use the vtable entry to call the
subclass's allocating constructor.
Most of the IRGen work here is hacking around the lossy SILDeclRef ->
(Code|Function)Ref -> SILDeclRef conversion. I'd feel bad about this
if John hadn't already agreed to clean this up at some point.
Swift SVN r14238
