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
would produce temporary stack allocations. Before the dealloc_stack would get
generated at the end of the foreach sequence, a violation the stack nesting verifier
caught.
Swift SVN r11673
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
If there's no script-mode file in a module, don't produce a top_level_code SILFunction for it, and don't consider emitting an LLVM global_ctor for it. We should never emit static constructors from user code anymore.
Swift SVN r11644
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
We should be able to cut out another layer of IRGen grime now.
This does XFAIL one test, test/Prototypes/TextFormatting.swift, which fails because of a weird archetype ordering in a nested substitution list. This should get sorted out by switching to interface types, so I'm going to let it go until then.
Swift SVN r11618
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
These still can't ever take any extra polymorphic params without breaking the calling convention, so protocol_method still needs to produce a thin value in SIL, and we have to ensure we don't add any extra polymorphic params in the IR signature.
Swift SVN r11594
r11586 is still too weak to handle both a label and an abstraction change. Instead of trying to handle this case in the guts of the reabstraction machine, where it ends up breaking other things, pre-sanitize the witness and requirement types before feeding them in. This is gross, but the keyword overhaul will hopefully make this unnecessarily before long.
Swift SVN r11588
Gratuitously stripping the labels interferes with (T : U -> V) abstraction changes. Only strip the labels where strictly necessary for correct behavior for now.
Swift SVN r11586
In a case like:
protocol LabeledRequirement {
func method(x: Loadable)
}
struct UnlabeledWitness : LabeledRequirement {
func method(_: Loadable) {}
}
The original requirement type is represented as a labeled single-element TupleType, and the witness is represented as a scalar, but we want to disregard the label and consider the scalars in parallel. Do a pre-pass to strip single-element labels first before trying to destructure or indirect tuples.
Swift SVN r11580
This matches what SIL expects for generic function applications. Add a 'getPrimarySubstitutions' convenience method to ConcreteDeclRef.
Swift SVN r11579
'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
