Teach SILGen to handle function representation changes as part of function conversion instead of needing to be spoonfed a special expr for the purpose. Handle representation changes in both directions to and from blocks using the same logic as the bridging conversions.
Swift SVN r16318
We're still building tuple types that involve lvalues in the type
checker. Generally, tuple-to-tuple conversion fixes these up, but the
tuple-to-scalar conversion was not. Fixes <rdar://problem/16555384>.
Swift SVN r16191
Make it the conversion function's responsibility to addressof the inout if it wants that pointer. For things like mutable array conversion, we actually want the original inout as a parameter, particularly so we can call _makeUnique on it without disturbing its reference count.
Swift SVN r16090
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
If we don't do the inout qualification, then we end up building a load of the base, which breaks the writeback chain, causing <rdar://problem/16525257>.
Swift SVN r15961
- Set the direct bit on accesses to "Stored" properties, not just "stored
with trivial accessors" ones. This solves a ordering problem when analyzing
uses of the property before it gets promoted to having trivial accessors.
- Chance our computation of "being directly defined on the type" to look through
extension declcontexts, so we consider init methods in extensions to be
directly defined on the type.
This is a prerequisite for other changes I'm working on, NFC from these alone.
Swift SVN r15949
Lower LValueConversionExprs to LValueConversionComponents of SILGen's LValues, which add the conversion pair as a logical component of a writeback chain.
Swift SVN r15771
Add a third branch to the constraint system for '&x' expressions that allows conversion from an lvalue to a type via an additional writeback step:
- Add an LValueConversionExpr node that converts from @lvalue T to @lvalue U, given a pair of functions that convert T -> U and U -> T, to represent the writeback temporary.
- Allow conversion in an inout expression from @lvalue T to a type U that has the following members:
static func __writeback_conversion(Builtin.RawPointer, T.Type) -> U
static func __writeback_conversion_get(T) -> V
static func __writeback_conversion_set(V) -> T
which builds a solution that produces an LValueConversion from the get/set pair before passing the pointer to the writeback temporary off to the conversion function.
Swift SVN r15764
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
Optional type,
The attempt to coerce the operand to UncheckedOptional for
dynamic member accesses leads to an inconsistency when
applying the constraint solution because we haven't figured
out how to convert to UncheckedOptional<T> --- all the
conversion restrictions are to optional type.
The test case will be part of the standard test suite when
applying the UncheckedOptional import patch.
In order to continue to work around weaknesses in SILGen's
function conversion code, peephole optional conversion in
the function application path.
Swift SVN r15651
We'll need types to be convertible from multiple kinds of inouts, which currently can't be represented with protocol conformance since we only allow one protocol conformance per type per protocol. Instead just look for a magic "__inout_conversion" static method in the type; this is lame but easy, and inout conversions shouldn't be available outside of the stdlib anyway.
Swift SVN r15599
Implement lowering for the LValueToPointer and InOutConversion expressions. For the former, we emit the lvalue, then convert it to a RawPointer; for the latter, we introduce an InOutConversion scope, which suppresses any nested writeback conversion scopes.
This completes the implementation of inout address conversion, except that we don't implement reabstraction of the lvalue prior to taking its address. Simply report them unimplemented for now, since reabstraction should not come up for our immediate use case with C types.
Swift SVN r15595
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
