The changes to allow for partial consumption unintentionally also allowed for
`self` to be consumed as a whole during `deinit`, which we don't yet want to
allow because it could lead to accidental "resurrection" and/or accidental
infinite recursion if the consuming method lets `deinit` be implicitly run
again. This makes it an error again. The experimental feature
`ConsumeSelfInDeinit` will allow it for test coverage or experimentation
purposes. rdar://132761460
As-is, this default interferes with the incremental build machinery which conservatively assumes that binary module dependencies must cause dependents to be re-built.
As of now, SE-366 is not correctly implemented with respect to concrete,
bitwise-copyable types like `Int`. Writing `consume someInt` doesn't
actually consume the variable binding as it should, meaning code that
should be flagged as having a use-after-consume is being silently
permitted:
```swift
let someInt = 10
let y = consume someInt
print(someInt) // no error!
```
This has been a problem since Swift 5.9. Eventually we plan to fix this
issue, which means code previously doing the above would become an
error. To help people get ready for the fix, start warning people that
these consumes are actually no-ops and suggest removing them until the
intended behavior is actually enforced in the future.
resolves rdar://127081103
Always add constraints, find fixes during simplify.
New separate fix for allow generic function specialization.
Improve parse heuristic for isGenericTypeDisambiguatingToken.
Upstreams the necessary changes to compile references to `@backDeployed`
declarations correctly when a `macabi` target triple or a `-target-variant` is
specified.
We don't yet have keypaths working correctly to allow access to
noncopyable fields, so we should raise a friendly error in Sema rather
than an error-out elsewhere vaguely.
resolves rdar://109287447
Attempting to bypass the compiler and access runtime functions directly has
a long history of breaking in hard-to-predict ways, and there's usually a better
way. Put up a warning to try to flush out misuses of runtime functions to see
if we can turn this into an error.
Previously we could end up with a
ContextualMismatch fix and a MissingConformance fix
for different elements of the `matchTypes` disjunction,
leading to an ambiguity. Instead, avoid recording
the ContextualMismatch if we're matching an
existential, and tweak the MissingConformance
failure to have a custom diagnostic for
EnumElementPattern matching.
