Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
This eliminates a class of strange type checking failures involving
generics. The actual example is from <rdar://problem/15772601>, but
this also addresses <rdar://problem/15268030> and the root problem,
<rdar://problem/15168483>.
Swift SVN r12974
Use the just-introduced functionality to track the member types of a
type variable to allow type substitution to look up a member type of a
type variable, rather than failing to substitute. NFC yet.
Swift SVN r12972
This eliminates the duplication of type variables that represent the member types of existing type variables. I'm unable to trigger this with a test case at the moment, but it becomes important when we begin to substitute type variables through protocol conformances.
Swift SVN r12971
to non-@mutating methods work in the AST: now the base expression is
always computed as an rvalue, instead of computing them as an lvalue. The
optimization that we were accidentally getting before is now explicitly
modeled, and the non-optimized case is now handled by standard temporary
emission in SILGen instead of with MaterializeExpr. The upshot of this
carefully choreographed step is that there is no change in generated code (!).
Archetype member references still need to be switched over to this new
scheme (at which point materializeexpr is dead), and the optimization
needs to be replicated for 'let' bases (at which point arguments
becoming 'let' is only gated on debug info).
Swift SVN r12120
- MaterializeExpr can never be formed in an argument list (but
still can as the base object) so remove that case from CSApply.
- LValues never exist *inside* of tuples, so remove code related
to that.
Swift SVN r11889
- Change the AST for get/set functions to take self @inout only when they
are @mutating. Setters default to @mutating, but can be explicitly marked
@!mutating. Getters default to not mutating, but can be marked @mutating.
This causes self to follow.
- Change sema to handle semantic analysis of a.y (and subscripts) based on
whether the computed type of a allows mutation (which is when 'a' is an
lvalue, or both the getter and setter are non-mutating). When both of
these conditions fail, 'a.y' has rvalue type, and is thus non-mutable.
- Rework silgen of lvalues to handle this: now properties and subscripts
can have rvalues as bases, which means that all the lvalue machinery needs
to be able to handle the full generality of base expressions (which is
what my recent patches have been paving the way towards).
- Rework silgen of rvalues to similarly handle rvalue bases.
- Rework silgen of both to handle the case where the AST has found a base
expression that is an lvalue, but where only a non-mutating getter or
setter is needed. Right now, we just emit a load of the lvalue, but
it would result in better code to not require the base be an lvalue at
all (todo).
The upshot of all of this is that we are doing *much* less AST-level
materialization (MaterializeExpr goes down), we generate a lot better SIL
out of SILGen in many cases, and 'self' being an rvalue in properties and
subscripts means that we correctly reject code like the examples in
test/Sema/immutability.swift.
Swift SVN r11884
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
- Switch all the 'self' mutable arguments to take self as @inout, since
binding methods to uncurried functions expose them as such.
- Eliminate the subtype relationship between @inout and @inout(implicit),
which means that we eliminate all sorts of weird cases where they get
dropped (see the updated testcases).
- Eliminate the logic in adjustLValueForReference that walks through functions
converting @inout to @inout(implicit) in strange cases.
- Introduce a new set of type checker constraints and conversion kinds to properly
handle assignment operators: when rebound or curried, their input/result argument
is exposed as @inout and requires an explicit &. When applied directly (e.g.
as ++i), they get an implicit AddressOfExpr to bind the mutated lvalue as an
@inout argument.
Overall, the short term effect of this is to fix a few old bugs handling lvalues.
The long term effect is to drive a larger wedge between implicit and explicit
lvalues.
Swift SVN r11708
struct rvalue, to produce a struct element directly, without converting the rvalue
to an lvalue.
This means that it no longer materializes an lvalue when applied to a let declaration
or other rvalue. For example, this testcase:
struct X { var a,b : Int}
func g() -> X { return X(1,2) }
func f() {
let a = g().a
}
used to sema into:
(load_expr implicit type='Int'
(member_ref_expr type='@inout (implicit, nonsettable)Int' decl=t.(file).X.a@t.swift:2:16
(materialize_expr implicit type='@inout (implicit)X'
(call_expr type='X'
and silgen into:
%1 = function_ref @_TF1t1gFT_VS_1X : $@thin () -> X // user: %2
%2 = apply %1() : $@thin () -> X // user: %4
%3 = alloc_stack $X // users: %7, %5, %4
store %2 to %3#1 : $*X // id: %4
%5 = struct_element_addr %3#1 : $*X, #a // user: %6
%6 = load %5 : $*Int64
It now sema's into:
(member_ref_expr type='Int' decl=t.(file).X.a@t.swift:1:16
(call_expr type='X'
and silgens into:
%1 = function_ref @_TF1t1gFT_VS_1X : $@thin () -> X // user: %2
%2 = apply %1() : $@thin () -> X // user: %3
%3 = struct_extract %2 : $X, #a
I think I'm finally starting to grok Doug's crazy typechecker magic.
Swift SVN r11599
As part of this, take away the poor attempt at recovering by adding an
explicit protocol conformance. The recovery mode isn't all that useful
in a system with only explicit conformance, and it messes with
diagnostics further down the line. We can bring it back later once
we're happy with explicit conformance checking.
Swift SVN r11503
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
A SpecializedProtocolConformance intentionally contains all of the
information we need to synthesize the type witnesses from the
underlying (generic) conformance. Do so lazily rather than eagerly,
because we won't always need all of them.
As a nice side effect, we no longer need to serialize the witnesses of
these specialized protocol conformances, so we can save some space in
the Swift module file.
Swift SVN r11303
