- 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
- mark closure arguments (both explicit and $0's) as immutable
- Adjust the stdlib (one place) and some tests to cope with this.
- Remove some special case logic in sema for lvalue qualifying
anonymous closure exprs, which is now the wrong thing to do.
Swift SVN r11674
- In AST/Decl.cpp, simplify by always setting isMutating to true for
ctors/dtors, since mutability only means something to struct/enum
methods anyway.
- in DeclContext.cpp, continue to lvalue qualify the 'self' of protocol
methods, this is currently dead.
- in CSApply, fix logic for some value-type member processing stuff
to properly handle methods that have a self which is not lvalue
qualified. Not exercised yet.
Swift SVN r11650
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
(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
Similar to r11235, but for 'is' expressions. QoI suffers somewhat here
because (1) we don't have an easy way to specialize the diagnostic,
and (2) we can't fix up the broken constraint system when we hit a
problem.
Swift SVN r11241
Previously, we had an artificial separation between the subexpression
"x" and the context of the expression "x as T". This breaks down when
the subexpression includes a reference to an anonymous closure
argument (e.g., $0) from a single-expression closure. By merging the
systems, we fix the crasher (<rdar://problem/15633178>) and allow
improved type inference for these expressions.
Swift SVN r11235
Notice that I'm hacking the test to get it running again. I'd normally
feel bad about this, but since labeled tuple elements are going away,
the class of problems this commit is working around will disappear
entirely.
Swift SVN r11115
