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
handle cases where the index lowers to exactly identical SILValue's. This is presently
pretty uncommon (except in the moderately common case of a direct reference to a "let Int"),
but is a nice base case.
The diagnostic we now get is:
t.swift:5:23: error: inout writeback through subscript occurs in multiple arguments to call, introducing invalid aliasing
swap(&array[i][j], &array[i][i])
^~~~~~~~ ~
t.swift:5:9: note: concurrent writeback occurred here
swap(&array[i][j], &array[i][i])
^~~~~~~~ ~
based on the fact that "i" lowers to the same SILValue.
Swift SVN r20376
introduced, as these are obvious miscompilations and clearly mystifying to our user base.
This is enough to emit diagnostics like this:
writeback_conflict_diagnostics.swift:58:70: error: inout writeback aliasing conflict detected on computed property 'c_local_struct_property'
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
writeback_conflict_diagnostics.swift:58:33: note: concurrent writeback occurred here
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
which isn't great, but is better than nothing (better wording is totally welcome!).
This doesn't handle subscripts (or many other kinds of logical lvalue) at all yet, so
it doesn't handle the swift WTF case, but this is progress towards that.
Swift SVN r20297
to give it a trivial amount of CSE. This isn't important generally (global_addr turns into
a trivial constant in LLVM IR) but unblocks some other SILGen stuff I'm working on.
This doesn't affect lazy global addressors.
Swift SVN r20259
Add a set of _preconditionOptionalHasValue intrinsics that merely test that an optional has a case. Emit an lvalue ForceValueExpr as a physical lvalue, first asserting the precondition then projecting out the Some payload.
Swift SVN r20188
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
completely destroyed when forwarded.
Also, make forwarding a cleanup a first-class operation
on cleanups, rather than setting the cleanup state directly.
Swift SVN r19332
We no longer need this language feature. The Sema support is still skeletally kept in place because removing it seems to totally break pointer conversions; I need to work with Joe and Doug to figure out why that's the case.
Swift SVN r19289
unconditional_dynamic_cast_addr instruction.
Also, fix some major semantic problems with the
existing specialization of unconditional dynamic
casts by handling optional types and being much
more conservative about deciding that a cast is
infeasible.
This commit regresses specialization slightly by
failing to turn indirect dynamic casts into scalar
ones when possible; we can fix that easily enough
in a follow-up.
Swift SVN r19044
The CALayer brittleness in <rdar://problem/17014037> is worse than we thought—we can't r/r *at all* before super.init. Go through some contortions to ensure that, when doing direct stored property access in an initializer, we always base off of a +0 value. I tried fixing this in a more general and principled way using SGFContext::AllowPlusZero, but that introduced miscompiles we don't have the luxury of tracking down right now, so hack a more targeted fix that only affects class initializers.
Swift SVN r18635
at the SIL level. Now, the referent type of a WeakStorageType is always
an optional type, instead of always being the underlying reference. This
allows us to represent both optional types. Before, both of these had the
same AST representation of WeakStorageType(T):
weak var x : T?
weak var x : T!
which doesn't work. Now we represent the optional type explicitly in the
AST and at SIL level. This also significantly simplifies a bunch of code
that was ripping off the optional type and resynthesizing it in other places,
and makes SILGen of weak pointers much more straight-forward by eliminating
the need for emitRefToOptional and emitOptionalToRef entirely (see the diffs
in test/SILGen/weak).
Weak pointers still have problems, but this is a big step forward.
Swift SVN r18312
an interior node that remaps the weak/unowned storage representation to its
strong rvalue representation. This allows it to chain on top of ValueComponent
and other memory-addressing things. NFC.
Swift SVN r17931
This reworks handling of weak/unowned values to represent them as logical
lvalues instead of as physical lvalues. Representing them as physical
lvalues breaks a lot of assumptions throughout silgen because (while they
have the same in-memory representation) weak pointers and optional have
different dynamic behavior.
This will hopefully make weak pointers generally more reliable than they
have been. One causualty of this is that the "copy_addr" peephole is defeated
for the case that you copy a weak lvalue to another weak lvalue, but correctness
needs to win, and this can be added back later when it becomes a priority.
Swift SVN r17842
This was part of the original weak design that
there was never any particular reason to rush the
implementation for. It's convenient to do this now
so that we can use it to implement Unmanaged<T> for
importing CF types.
Swift SVN r16693
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
Check that a physical lvalue's lowered type is actually different from what we get if we load the lvalue before introducing a reabstraction writeback. Fixes <rdar://problem/16530674>.
Swift SVN r15970
