Emphasize the fact that this address is only intended for initialization. When we split destructive_switch_enum_addr, there will be another similar instruction for destructively taking the payload out of an already-initialized enum.
Swift SVN r12000
Treat the interface types of SILFunctionTypes as the canonical representation in the verifier. Do a bunch of supporting and annoyingly irreducible work to enable this:
- Stop trying to uncurry generic parameter lists during type lowering and preserve the structure of AST GenericParamLists. This makes mapping dependent types into contexts easier.
- Properly walk generic parameter lists at all depths when grooming substitution vectors for use with substGenericArgs interfaces.
- Reseat the generic parameter lists created for protocol_method results so that we don't expect the outer Self archetype to be unbound; it's provided by the extra data of the result.
- Hack SILFunctionType serialization never to use a decl reference when serializing its generic param list. When this happens, we get incorrect archetypes. This is a gross hack, but when we're able to jump all the way to interface types, it can go away.
Putting these ducks in a row nicely un-XFAILs TextFormatting.swift.
Swift SVN r11989
While we're here, cache the result of looking for delegation or
chaining calls within ConstructorDecl. Only Sema and SILGen for the
body of the constructor care, so we don't serialize this
information. Rather, we have a faster-path to recompute it should
someone ask again after it was cached.
Swift SVN r11969
As with chaining initialization ('super.init' calls), wrapping the
delegating initialization in RebindSelfInConstructorExpr ensures that
'self' gets overwritten by the result of delegation.
Note that I'd much prefer that RebindSelfInConstructorExpr be
introduced by the type checker (not the parser). That cleanup will
follow.
Swift SVN r11932
SIL instruction. Implement IR-gen support for same. Fix
the parsing of SIL string literals to properly unescape them.
SIL-gen still emits UTF8 literals unconditionally.
Swift SVN r11904
- 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
making LValue ManagedValues, and switch SILGenLValue to use
this form of managed value consistently for lvalues, instead of
using unmanaged values in some cases. NFC.
Swift SVN r11878
the things that apparently care about it. The LValue/RValue machinery is
happy to pass around the VarDecl/SubscriptDecl for the entity being
referenced, and this simplifies things.
Swift SVN r11857
not as part of the lvalue path. This means that the arguments to a
function (for example) are always rvalues - @inout arguments are not a
special case all over the place.
This removes emitLValueOrRValueAsRValue and emitLValueAsRValue, because
the lvalue that both of them were trying to handle was @inout, not @lvalue.
Swift SVN r11805
I originally wrote to turn "loadexpr(declrefexpr(letdecl))" is dead, remove
it. Let decls are now always rvalues, so they never are loaded.
Swift SVN r11804
is no longer an lvalue, since it doesn't make sense to assign to super.
This eliminates a bunch of special cases and simplifies things.
Swift SVN r11803
- Introduce a new TypeBase::getInOutObjectType() that strips off @inout types
- Switch stuff that is calling getRValueType() to call getInOutObjectType()
when they are stripping @inout, not @lvalue (this is primarily around
stuff working with self)
- Update testcases, some diagnostics improve around & handling.
This fixes rdar://15708430 and rdar://15729093.
Swift SVN r11794
This allows them to appear in argument lists of functions, enabling behavior
like this:
func test_arguments(a : Int, var b : Int, let c : Int) {
a = 1 // ok (for now).
b = 2 // ok.
c = 3 // expected-error {{cannot assign to the result of this expression}}
}
Swift SVN r11746
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
being closed over. If we allowed arguments to have tuple type
in the SILFunctionType type system, this would just work. As it is,
we have to do a bit of [re|de]structuring on the partial_apply and
the closure body side to work things out.
Swift SVN r11680
struct methods. This does not including properties and subscripts,
but covers the bulk of the change. The implication of this is that
the compiler now rejects mutations of self in a non-@mutating method,
and rejects attempts to call a @mutating method from a non-@mutating
method.
Along with this:
- Fix a refcounting bug in SILGenExpr where I emitted multiple releases
in the rvalue member_ref_expr case, which was exposed by the
testsuite now that rvalues are being used a lot more.
- Change a few native binding things in objc/Foundation to understand
that String is passed by value now when calling size() and that
you can't take the address of self in a non-mutating method (this
should probably pass the components by value instead of passing
&self, for better performance). I filed rdar://15726720 to track
this.
- Update a ton of testcases. We now don't materialize nearly as much
as we used to.
- Brutalize the test/stdlib/Getopt.swift testcase to work, now that
the "GetoptLongOptions().noArgument("foo")" builder pattern doesn't
work anymore (noArgument is a @mutating method, which isn't allowed
on an rvalue temporary).
Swift SVN r11662
properties are represented as rvalues, not non-mutable lvalues. As part of
this, isReferencedAsLValue() only returns true for mutable VarDecls.
This required some pretty serious rearrangement and refactoring of code,
because now (among other things) get-only properties can be emitted as rvalues,
so the rvalue machinery needs to be able to produce getter calls.
This is an important step towards getting proper value semantics going (for
'let's etc) and also allows us to materialize addresses less often. As a
simple example, before we would silgen this:
struct S {
var i : Int
}
var P : S { get: ... }
func f() {
print(P.i)
}
into:
%2 = function_ref @_TF1tg1PVS_1S : $@thin () -> S // user: %3
%3 = apply %2() : $@thin () -> S // user: %5
%4 = alloc_stack $S // users: %9, %6, %5
store %3 to %4#1 : $*S // id: %5
%6 = struct_element_addr %4#1 : $*S, #i // user: %7
%7 = load %6 : $*Int64 // user: %8
now we generate:
%2 = function_ref @_TF1tg1PVS_1S : $@thin () -> S // user: %3
%3 = apply %2() : $@thin () -> S // user: %4
%4 = struct_extract %3 : $S, #i // user: %5
Swift SVN r11632
container. Previously we destroyed just the accessed element, not the entire container.
Thanks to Joe for the consult on the best (and simpler!) way to fix this.
Swift SVN r11615
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
'let' declarations +1. This isn't used yet, as the peephole around LoadExprs
is still doing all the work here (and it is already +1 correct).
Swift SVN r11573
only handle rvalues. Clients that can either have an lvalue or an rvalue (which
are few, and will be diminishing as other planned changes happen like the tuple
vs argument split) use a specific api to indicate such.
Swift SVN r11572
...rather than a raw pointer that points to a buffer with space for N
elements. Just because we *can* get N from context doesn't mean it's
convenient/safe.
No functionality change.
Swift SVN r11488
Insert calls to super.init at the end of the class initializers that don't
reference any other initializers but have parents. The check for initializer
eligibility, expression construction, and typechecking are done on the AST level.
However, we insert the call inside the epilog block at SILGen to ensure that
constructors with early returns are handled properly.
Addresses radar://13108250.
Swift SVN r11444
as values, without a box at all. This generalizes some of the
previous hacks I had for silgen'ing 'self' as a value instead of
a box, and capturing them with CaptureKind::Constant.
Swift SVN r11360
loops as 'let', silgen isn't ready for it yet.
Change silgen's handling of let variables to stop using emitLoweredCopyValue,
which is busted for aggregates that contain both trivial and nontrivial types
(15669586).
Swift SVN r11352
allocating a box for them. When self is not marked inout (which will be
the default for structs someday) it changes the codegen of:
struct Foo {
...
func testfunction() -> Foo {
return self
}
}
To:
sil @_TV1t3Foo12testfunctionfS0_FT_S0_ : $@cc(method) @thin (Foo) -> Foo {
bb0(%0 : $Foo):
%1 = tuple ()
return %0 : $Foo // id: %2
}
instead of allocating a box, doing a store to it, etc.
Also included: don't maintain references into VarLoc where a simple copy
of the element would suffice. This isn't important, but was part of my
silvtable debugging and seems like the right thing.
Swift SVN r11307
location of variables at SIL generation time.
This patch introduces a SILDebuggerClient that
knows how to resolve the locations of variables
that are generated by the debugger. These
variables have a flag on them that only LLDB
sets.
Swift SVN r11230
This removes an oddity in the AST whereby the 'self' declaration
within a value type constructor was not represented as @inout, despite
having @inout semantics in the language.
Swift SVN r11194
