- 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
