We need this in order to unpin at the correct moment.
Add an assertion that there's a scope active when pushing
an unpin writeback, as well as an assertion to ensure that
we never finish a function with writebacks active.
Swift SVN r24411
Permit non-Ordinary accesses on references to functions,
with the semantics of devirtualizing the call if the
function is a class member. This is important for
constructing direct call to addressors from synthesized
materializeForSet accessors: for one, it's more
performant, and for another, addressors do not currently
appear in v-tables.
Synthesize trivial accessors for addressed class members.
We weren't doing this at all before, and I'm still not
sure we're doing it right in all cases. This is a mess.
Assorted other fixes. The new addressor kinds seem
to work now.
Swift SVN r24393
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
use a thin function type.
We still need thin-function-to-RawPointer conversions
for generic code, but that's fixable with some sort of
partial_apply_thin_recoverable instruction.
Swift SVN r24364
The base value can be an address if it's any address-only type, not exclusively archetypes or existentials. Fixes nonmutating setters of address-only structs (rdar://problem/17841127), which I ran into while writing test cases for +0 self.
Swift SVN r24327
optional callback; retrofit existing implementations.
There's a lot of unpleasant traffic in raw pointers here
which I'm going to try to clean up.
Swift SVN r24123
teach SILGenLValue that let values guarantee the lifetime of their value for at least
the duration of whatever expression references the let value. This allows us to eliminate
retains/release pairs in a lot of cases, and provides more value for people to use let
instead of var. This combines particularly well with +0 self arguments (currently just
protocol/archetype dispatches, but perhaps someday soon all method dispatches).
Thanks to John for suggesting this.
Swift SVN r24004
SILGen was emitting extraneous retains/releases on self when accessing let
properties in a class, leading to bogus diagnostics. Fixing this just
amounted to realizing that emitDirectIVarLValue is already safe w.r.t. +0
bases.
Swift SVN r23975
or pointer depends on another for validity in a
non-obvious way.
Also, document some basic value-propagation rules
based roughly on the optimization rules for ARC.
Swift SVN r23695
conservatively copying them.
Also, fix a number of issues with mutating getters that
I noticed while examining and changing this code. In
particular, stop relying on suppressing writeback scopes
during loads.
Fixes rdar://19002913, a bug where an unnecessary copy of
an array for a getter call left the array in a non-unique
state when a subsequent mutation occurred.
Swift SVN r23642
Previously, we were binding optional l-values only when
performing an access. This meant that other evaluations
emitted before the formal access were not being
short-circuited, even if the language rules said they
should be. For example, consider this code::
var array : [Int]? = ...
array?[foo()] = bar()
Neither foo nor bar should be called if the array is
actually nil, because those calls are sequenced after
the optional-chaining operator ?.
The way that we currently do this is to project out
the optional address during formal evaluation. This
means that there's a formal access to that storage
beginning with the formal evaluation of the l-value
and lasting until the operation is complete. That's
a little controversial, because it means that other
formal accesses during that time to the optional
storage will have unspecified behavior according to
the rules I laid out in the accessors proposal; we
should talk about it and make a decision about
whether we're okay with this behavior. But for now,
it's important to at least get the right short-circuiting
behavior from ?.
Swift SVN r23608
as +0 when the client requests it. This avoids emitting some pointless
retain/releases.
This finishes up:
<rdar://problem/17207456> Unable to access dynamicType of an object in a class initializer that isn't done
Swift SVN r22736
Use init_enum_data_addr and inject_enum_addr to construct optional values instead of the injection intrinsics, further simplifying -Onone IR. This not only avoids a call but also allows the frontend to emit optional payloads in-place in more cases, eliminating a lot of stack traffic.
Swift SVN r22549
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
The test/SIL/Serialization failures on the bot seem to be happening sporadically independent of this patch, and I can't reproduce failures in any configuration I've tried.
Swift SVN r22537
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
Swift SVN r22533
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
"self" needs to be materialized in these cases. We were handling methods correctly, but not property accesses. Fixes rdar://problem/18454204.
Swift SVN r22309
semantically valid way.
Previously, this decision algorithm was repeated in a
bunch of different places, and it was usually expressed
in terms of whether the decl declared any accessor
functions. There are, however, multiple reasons why a
decl might provide accessor functions that don't require
it to be accessed through them; for example, we
generate trivial accessors for a stored property that
satisfies a protocol requirement, but non-protocol
uses of the property do not need to use them.
As part of this, and in preparation for allowing
get/mutableAddressor combinations, I've gone ahead and
made l-value emission use-sensitive. This happens to
also optimize loads from observing properties backed
by storage.
rdar://18465527
Swift SVN r22298
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
auto-generated so that the unreachable code diagnostic
doesn't complain if it manages to inline the
materializeForSet.
No test case because this actually shouldn't come up
in practice: we should never be calling an implicit
materializeForSet accessor. That we are right now
is a separate bug.
rdar://18439493
Swift SVN r22272
Addressors now appear to pass a simple smoke-test; in
order to allow some parallel developement, I'll be
committing actual SILGen tests for this later and
separately.
Swift SVN r22243
accessors on non-dynamic storage.
This allows us to take advantage of dynamic knowledge
that a property is implemented as stored in order to
gain direct access to it instead of copying into a
temporary. When a class or protocol-member property
is expensive to copy, and particularly when it's of
copy-on-write type, such direct accesses can massively
improve the performance of a program.
We are currently only able to apply this when the
property is implemented purely as stored. A willSet
observer inherently blocks the optimization, but we
should be able to make it work even for properties
with didSet observers. This could be done by returning
an arbitrary callback from materializeForSet instead
of returning a flag indicating whether to call the
setter.
rdar://17416120
Swift SVN r22122
as a std::vector<std::unique_ptr<PathComponent>>. DiverseList memcpy's
around its buffer on copy and move operations. This seems safe with all
of the current implementations of Cleanup, but is absolutely not with the
LValue PathComponents. These things hold std::vectors, RValue (which has
an std::vector in it), and a bunch of other probably non-trivial things.
While we're in here, disable the copy constructor, since it isn't safe.
This doesn't harm mainline, but was burning me on a patch I'm working on.
When/if someone cares about performance optimizing this code, a better
approach would be to use an ilist + bump pointer allocator.
Swift SVN r21057
behaviorly correct code by CSE'sing subscripts that are identical.
Also, add a dump() method to PathComponent to help visualize / debug LValue structures.
Swift SVN r20661
computed property" errors when SILGen could determine that there was
an inout writeback alias, and have the code instead perform CSE of the
writebacks directly.
This means that we produce more efficient code, that a lot of things
now "just work" the way users would expect, and that the still erroneous
cases now get diagnosed with the "inout arguments are not allowed to
alias each other" error, which people have a hope of understanding.
There is still more to do here in terms of detecting identical cases,
but that was true of the previous diagnostic as well.
Swift SVN r20658
Factor out the code for emitting the "bind" branching logic, and share it to implement an LValueComponent for optional binds, which makes optional assignments work.
Swift SVN r20614
include the index which is confusing. For example, in:
func testMultiArray(i : Int, j : Int, var array : [[Int]]) {
swap(&array[i][j], &array[i][i])
}
we now highlight just "array[i]", instead of the subsequent "j" and "i"'s.
Swift SVN r20446
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
lower to different SILValue's are actually identical. These are the expression involved
in turning an integer literal into an expression. This is totally a hack in that we assume
that all "convertFromIntegerLiteral" are side effect free, but is close enough to be useful
for this diagnostic. The right answer is to implement real attributes to model this
(rdar://15587352).
That said, this diagnostic is pretty useful as it is. For example, the SwiftWTF blog post
(http://swiftwtf.tumblr.com/post/91934970718/xcode-6-beta-3) has two examples. The first
one passes this diagnostic unscathed because there is no inout aliasing problem: "a" is a
physical lvalue, not a logical one and a[1] doesn't alias a[2].
However, the second example is now rejected with an error message of:
t.swift:12:18: error: inout writeback through subscript occurs in multiple arguments to call, introducing invalid aliasing
swap(&aa[0][1], &aa[0][2])
^~~~~ ~
t.swift:12:7: note: concurrent writeback occurred here
swap(&aa[0][1], &aa[0][2])
^~~~~ ~
This is a violation even though "aa" is physical lvalue, because "aa[0]" is a logical
lvalue and we can now detect that the two instances of "aa[0]" are identical (because
we can tell the two 0's are identical). I'm still not thrilled with the diagnostic, but
I think this will help stem a common source of problems in practice.
As more lvalues become physical or get auto-CSE'd (either with better SILGen CSE, with
physical i addressors, etc) this diagnostic will automatically track SILGen.
Swift SVN r20377
