The reason I am doing this is that we have gotten reports about certain test
cases where we are emitting errors about self being captured in isolated
closures where the sourceloc is invalid. The reason why this happened is that
the decl returned by getIsolationCrossing did not have a SourceLoc since self
was being used implicitly.
In this commit I fix that issue by using SIL level information instead of AST
level information. This guarantees that we get an appropriate SourceLoc. As an
additional benefit, this fixed some extant errors where due to some sort of bug
in the AST, we were saying that a value was nonisolated when it was actor
isolated in some of the error msgs.
rdar://151955519
(cherry picked from commit f31236931b)
Defer visiting an instruction until its operands have been visited. Otherwise,
this pass will crash during ownership verification with invalid operand
ownership.
Fixes rdar://152879038 ([moveonly] MoveOnlyWrappedTypeEliminator ownership
verifier crashes on @_addressableSelf)
(cherry picked from commit 16fffd1704)
Issue:
When using a densemap subscript expression on both sides of an
assignment in the same statement of the same map we run into the issue
that the map can reallocate because of the assignment but we are
referencing the value of the RHS map subscript by reference --
i.e we can reference deallocated memory.
Not good.
Scope: A "silent" memory error that one might run into including the
reporter of the bug.
Risk: Extremely, low. The fix is spliting an assignment from a map value
to a map entry into: A value assignment of the map value to a local. And
then storing the local in the map entry forgoing the reference of
reallocated memory bug.
```
valueMap[bfi] = valueMap[bfi->getBorrowedValue()];
=>
auto mappedMValue = valueMap[bfi->getBorrowedValue()];
valueMap[bfi] = mappedValue;
```
Reviewed by: Meghana G, Erik E., Joe G.
Testing: The fix was tested on the reporting project.
rdar://151031297
When creating a tuple, the type needs to be specified because otherwise, if the original tuple has labels, it will cause a type mismatch verification error.
rdar://152588539
A destroy of an `init_enum_data_addr` is not equivalent to a destroy of
the whole enum's address. Treat such destroys just like destroys of
`struct_element_addr`s are treated: by bailing out.
rdar://152431332
In this case, what is happening is that in SILGen, we insert implicit
DistributedActor.asLocalActor calls to convert a distributed actor to its local
any Actor typed form. The intention is that the actor parameter and result are
considered the same... but there is nothing at the SIL level to enforce that. In
this commit, I change ActorInstance (the utility that defines actor identity at
a value level) to look through such a call.
I implemented this by just recognizing the decl directly. We already do this in
parts of SILGen, so I don't really see a problem with doing this. It also
provides a nice benefit that we do not have to modify SILFunctionType to
represent this or put a @_semantic attribute on the getter.
NOTE: Generally, Sema prevents us from mixing together different actors. In this
case, Sema does not help us since this call is inserted implicitly by the
distributed actor implementation in SILGen. So this is not a problem in general.
rdar://152436817
(cherry picked from commit 331626e6fa)
Otherwise, depending on the exact value that we perform the underlying look up
at... we will get different underlying values. To see this consider the
following SIL:
```sil
%1 = alloc_stack $MyEnum<T>
copy_addr %0 to [init] %1
%2 = unchecked_take_enum_data_addr %1, #MyEnum.some!enumelt
%3 = load [take] %2
%4 = project_box %3, 0
%5 = load_borrow %4
%6 = copy_value %5
```
If one were to perform an underlying object query on %4 or %3, one would get
back an underlying object of %1. In contrast, if one performed the same
operation on %5, then one would get back %3. The reason why this happens is that
we first see we have an object but that it is from a load_borrow so we need to
look through the load_borrow and perform the address underlying value
computation. When we do that, we find project_box to be the value. project_box
is special since it is the only address base we ever look through since from an
underlying object perspective, we want to consider the box to be the underlying
object rather than the projection. So thus we see that the result of the
underlying address computation is that the underlying address is from a load
[take]. Since we then pass in load [take] recursively into the underlying value
object computation, we just return load [take]. In contrast, the correct
behavior is to do the more general recurse that recognizes that we have a load
[take] and that we need to look through it and perform the address computation.
rdar://151598281
(cherry picked from commit 904ebc6784)
This prevents simplification and SILCombine passes to remove (alive) `mark_dependence_addr`.
The instruction is conceptually equivalent to
```
%v = load %addr
%d = mark_dependence %v on %base
store %d to %addr
```
Therefore the address operand has to be defined as writing to the address.
Not used (yet), but needed to implement SIMD.replacing(with:where:)
idiomatically, and probably useful otherwise.
**Explanation:** Makes select available in Swift's builtin module, which
allows implementing concrete SIMD operations more efficiently.
**Risk:** Low. New builtin protected by a feature flag, currently
unused.
**Testing:** New tests added.
**Reviewers:** @eeckstein, @Azoy
**Main branch PR:** https://github.com/swiftlang/swift/pull/81598
When the called closure throws an error, it needs to clean up the buffer.
This means that the buffer is uninitialized at this point.
We need an `end_lifetime` so that the move-only checker doesn't insert a wrong `destroy_addr` because it thinks that the buffer is initialized.
Fixes a mis-compile.
rdar://151461109
Apply the MoveOnlyAddressChecker change from
https://github.com/swiftlang/swift/pull/73358 to the
MoveOnly[Value]Checker.
After 7713eef817, before running value
checking, all lifetimes in the function are completed. That doesn't
quite work because lifetime completion expects not to encounter
reborrows or their adjacent phis.
rdar://151325025
Currently we delete dead drop_deinit instructions in InstructionDeleter. For address results, we may end up with ownership errors after being promoted to value forms. For value results, fixLifetimes mode of InstructionDeleter will insert an illegal destroy_value
rdar://151104993
Prevent sinking of stores if there are instructions other than `load` which may read from memory.
This kind of memory dependencies were ignored.
Fixes SIL verifier crashes or - in worst case - miscompiles.
rdar://150205299
In language 6 mode keypath instructions are created as existentials and the optimizer needs to look through the `open_existential_ref` instructions to recognize a keypath.
rdar://150173106
The SimplifyCFG and LoopRotate passes result in verification failures
when built in a compiler that is not built with Swift sources enabled.
- Scope: Disables optimizers passes in C++-only compiler for
bootstrapping purposes. Has no impact on full Swift compiler build.
- Risk: Low. This change has no impact in build environments where a
Swift compiler is available.
- Reviewers: @eeckstein
- Testing: PR testing -- Full PR testing fails if passes are
accidentally disabled.
Fixes: rdar://146357242
(cherry picked from commit bca1378fdb)
Enable walking into `TypeOffsetSizePair`s from an existential into an
archetype. And set the access kind on `open_existential_addr`
instructions which are the sources of rewritten `copy_addr`s to mutable.
rdar://141279635
When the utility is used by the ConsumeOperatorCopyableValuesChecker,
the checker guarantees that the lifetime can end at the consumes, that
there are no uses after those consumes. In that circumstance, the
utility maintains liveness to those consumes and as far as possible
without introducing a copy everywhere else.
The lack of complete lifetimes has forced the utility to extend liveness
of values to dead-ends. That extension, however, is in tension with the
use that the checker is putting the utility to. If there is a dead-end
after a consume, liveness must not be maintained to that dead-end.
rdar://147586673
A metatype need not always come from a metatype instruction. It can come from
a SILArgument. Fix the invalid cast operation in OSLogOptimization.
Fixes rdar://146160325
