These wrappers are detected by the move checking passes,
to support the implicit no-implicit-copy check for
parameters with ownership specifiers.
ManualOwnership already does this kind of checking, and the
two passes can interfere with each other, such as intercepting
diagnostics that are meant to be emitted by ManualOwnership.
After #83959, we expect noncopyable OpenExistential evaluations to have an outer
FormalEvaluationScope to forward to. However, there was no such
FormalEvaluationScope while emitting a consuming switch subject, causing an assertion
failure to trip. Add a FormalEvaluationScope tightly scoped around the evaluation in
this case, fixing rdar://160080337.
We want to call the `bodyEmitter`, since that has the extra logic
necessary to handle `do-catch` statements. Previously this didn't
cause any issues since `hasCaseBodyVariables` would have always been
true for parsed `do-catch`s, but I'm planning on changing that.
There's no need for two separate types here. Fully separate the addressable buffer
tracking from VarLocs as well, in order to set up for a fix to addressable references
to `if let` and `guard let` bindings.
In order to accommodate case bodies with multiple case labels, the AST
represents the bindings in each pattern as a distinct declaration from
the matching binding in the case body, and SILGen shares the variable
representation between the two declarations. That means that the two
declarations also need to be able to share an addressable representation.
Add an "alias" state to the addressable buffer data structures so that
we can refer back to the original case label var decl when the case body
var decl is brought into scope, so that accesses through either decl
properly force the addressable representation.
Fixes rdar://154543619.
Don't bind references to storage to use (new ABI) coroutine accessors
unless they're guaranteed to be available. For example, when building
against a resilient module that has coroutine accessors, they can only
be used if the deployment target is >= the version of Swift that
includes the feature.
rdar://148783895
To ensure that dependent values have a persistent-enough memory representation
to point into, when an immutable binding is referenced as an addressable
argument to a call, have SILGen retroactively emit a stack allocation and
materialization that covers the binding's scope.
To ensure that dependent values have a persistent-enough memory representation
to point into, when an immutable binding is referenced as an addressable
argument to a call, have SILGen retroactively emit a stack allocation and
materialization that covers the binding's scope.
Introduce an `unsafe` expression akin to `try` and `await` that notes
that there are unsafe constructs in the expression to the right-hand
side. Extend the effects checker to also check for unsafety along with
throwing and async operations. This will result in diagnostics like
the following:
10 | func sum() -> Int {
11 | withUnsafeBufferPointer { buffer in
12 | let value = buffer[0]
| | `- note: reference to unsafe subscript 'subscript(_:)'
| |- warning: expression uses unsafe constructs but is not marked with 'unsafe'
| `- note: reference to parameter 'buffer' involves unsafe type 'UnsafeBufferPointer<Int>'
13 | tryWithP(X())
14 | return fastAdd(buffer.baseAddress, buffer.count)
These will come with a Fix-It that inserts `unsafe` into the proper
place. There's also a warning that appears when `unsafe` doesn't cover
any unsafe code, making it easier to clean up extraneous `unsafe`.
This approach requires that `@unsafe` be present on any declaration
that involves unsafe constructs within its signature. Outside of the
signature, the `unsafe` expression is used to identify unsafe code.
When a protocol which has a read (or modify) requirement is built with
the CoroutineAccessors feature, it gains a read2 (or modify2,
respectively) requirement. For this to be compatible with binaries
built without the feature, a default implementation for these new
requirements must be provided. Cause these new accessor requirements to
have default implementations by returning `true` from
`doesAccessorHaveBody` when the context is a `ProtocolDecl` and the
relevant availability check passes.
It should be impossible to reach an unexpected case statically while using
noncopyable enums, and the intrinsic has not been updated to remove its
`Copyable` requirement. Emit a plain trap in cases where this code emission
path might still occur, such as when a redundant but incomplete set of case
patterns follow a wildcard pattern. Fixes rdar://130037881.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
This isn't fully implemented yet so it would crash eventually, so instead of
letting the compiler crash put up a proper diagnostic indicating this isn't
yet implemented. rdar://129034189
To avoid breaking early adopters of this feature, accept attempts to `return`
a `let` binding in a noncopyable `switch` when it would be treated as a
borrow normally, with a warning that this behavior will change soon.
rdar://126775241
It works well enough now that it should be an acceptable replacement for both
borrowing and consuming switches that works in more correct situations than the
previous implementation. This does however expose a few known issues that I'll
try to fix in follow ups:
- overconsumes cause verifier errors instead of raising diagnostics (rdar://125381446)
- cases with multiple pattern labels aren't yet supported (rdar://125188955)
- copyable types with the `borrowing` or `consuming` modifiers should probably use
noncopyable pattern matching.
The `BorrowingSwitch` flag is still necessary to enable the surface-level syntax
changes (switches without `consume` and the `_borrowing` modifier, for instance).
If an expression refers to noncopyable storage, then default to performing
a borrowing switch, where `let` bindings in patterns borrow out of the
matched value. If an expression refers to a temporary value or explicitly
uses the `consume` keyword, then perform a consuming switch, where
`let` bindings take ownership of corresponding parts of the matched value.
Allow `_borrowing` to still be used to explicitly bind a pattern variable
as a borrow, with no-implicit-copy semantics for copyable values.
For address-only types, a temporary was emitted with the same debug variable
and same scope as the instruction it is moved to after entering a shared case,
but it would have a different type, which would create a conflict.
The better way to fix this would probably to use a different scope for both,
but the variable is moved immediately anyway.
Suppose you have an exhaustive switch statement which matches all the cases of
a Swift enum defined in a different module named `External`:
```
import External
var e: External.SomeEnum = //...
switch e {
case .a: break
}
```
If `External` is compiled with library evolution and `SomeEnum` is not frozen,
then the compiler will warn:
```
warning: switch covers known cases, but 'SomeEnum' may have additional unknown values
```
You add an `@unknown default` to the switch to resolve this warning. Now
suppose in another build configuration, `External` is built _without_ library
evolution. The compiler will complain about the unreachability of the default
case:
```
warning: Default will never be executed
```
These contradictory compiler diagnostics encourage the developer to change the
code in a way that will cause a diagnostic in the other configuration.
Developers should have the tools to address all warning diagnostics in a
reasonable fashion and this is a case where the compiler makes that especially
difficult. Given that writing `@unknown default` instead of `default` is a very
intentional action that would be the result of addressing the library evolution
configuration, it seems reasonable to suppress the `Default will never be
executed` diagnostic.
For years, optimizer engineers have been hitting a common bug caused by passes
assuming all SILValues have a parent function only to be surprised by SILUndef.
Generally we see SILUndef not that often so we see this come up later in
testing. This patch eliminates that problem by making SILUndef uniqued at the
function level instead of the module level. This ensures that it makes sense for
SILUndef to have a parent function, eliminating this possibility since we can
define an API to get its parent function.
rdar://123484595
We want to preserve the borrow scope during switch dispatch so that move-only
checking doesn't try to analyze destructures or consumes out of it. SILGen
should mark anywhere that's a potential possibility with its own marker so that
it gets borrow checked independently.
This prevents the move-only checker from trying to analyze the bindings
as partial consumptions, which ought to be unnecessary since SILGen
will always fully consume the subject as part of forming the bindings.
Fill in a missing path for destructuring loadable elements from
address-only tuples in a borrowing context. Enclose projections in their
own separate accesses so that they are analyzed independently by the
move checker.
Relax some existing pattern matches and add some unhandled instructions to the
walkers so that borrowing switches over address-only enums are properly analyzed
for incorrect consumption. Add a `[strict]` flag to `mark_unresolved_move_only_value`
to indicate a borrow access that should remain a borrow access even if the subject
is later stack-promoted from a box.
A `let` binding of a copyable subpattern can create an independent variable
which should be copyable and consumable without affecting a borrowed
move-only base. In the same way that `borrowing` parameters are
no-implicit-copy, though, explicitly `_borrowing` subpatterns of
copyable type should be no-implicit-copy as well.
