When migrating, provide warnings that add 'nonisolated' to nonisolated
conformances that don't already have it and would end up being inferred
to be isolated under the upcoming feature.
Adopters of the new Span and MutableSpan types should not encounter information
about an experimental feature when they attempt to use these types in
unsupported ways, such as simply returning them from a function.
Fixes rdar://151788740 (Diagnostic message: suppress printing "requires
'-enable-experimental-feature LifetimeDependence'")
When the attribute is specified explicitly passing a `@concurrent`
closure to a global actor-isolated parameter or contextual type
should result in a conversion and closure itself should be nonisolated.
Resolves: rdar://151797372
importer::findOptionSetEnum() uses some fragile heuristics to determine
whether a typedef is involved in the construction of a CF_OPTIONS or
NS_OPTIONS type. This patch adds an explicit check that the typedef is
expanded from either of those macros, to prevent, e.g., an unavailable
NS_ENUM, from being mistakenly recognized as an NS_OPTIONS.
Note that doing this is still kind of fragile, and prevents users from
building {NS,CF}_OPTIONS with their own macros. The right thing to do is
probably specifically look for the flag_enum attribute, but that is not
currently what we're doing for reasons whose discovery is left as
an exercise to the future git archaeologist.
This patch also removes (part of) a test case that builds
a CF_OPTIONS-like type with the "SOME_OPTIONS" macro, which is no longer
supported as of this patch.
rdar://150399978
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.
The NS_OPTIONS macro sometimes uses a pattern where it loosely
associates a typedef with an anonymous enum via a shared underlying
integer type (emphasis on "loosely"). The typedef is marked as
unavailable in Swift so as to not cause name ambiguity when we associate
the anonymous enum with said typedef. We use unavailability as
a heuristic during the import process, but that conflates NS_OPTIONS
with NS_ENUMs that can be marked as unavailable for entirely unrelated
reasons.
That in and of itself is fine, because the import logic is general
enough to handle both cases, but we have an assertion that seems to be
unaware of this scenario, and trips on unavailable NS_ENUMs. (In those
cases, the typedef points to the enum rather than the underlying integer
type.) This patch fixes the assertion to be resilient against such cases
by looking through the enum a typedef refers to.
rdar://150399978
Introduce a new ASTWalker option for walking CustomAttrs and use it
for the placeholder scanner to ensure we can expand placeholders in
attribute arguments.
Otherwise querying this clang module, e.g. from the corresponding Swift overlay's underlying module import, will fail, since no such module exists.
Resolves rdar://151718115
This matches the case that we use in the Runtimes build system, so we
rely the exported target instead of adding `-lswiftCore`.
Addresses rdar://151700669
When an "unsafe" expression is used as the case expression, lift it up
so it also covers the synthesized matching expression (`=~`). This
eliminates some unsuppressible strict memory safety warnings.
Fixes rdar://151731850.
Evaluating LifetimeDependence changes the order that the declarations are
diagnosed. Fix this test output by flipping the order of two declarations. The
new order actually makes more sense to me.
When reporting the declarations that lead to a cycle, we end up printing an
extra "through reference here" on the function declaration:
class C2: C1, P {
| |- note: through reference here
| `- note: through reference here
15 | // expected-note@-1 2{{through reference here}}
16 | override func run(a: A) {}
| | | `- note: while resolving type 'A'
| | `- note: through reference here
| |- error: circular reference
| |- note: through reference here
| `- note: through reference here
This adds a new lifetime inference rule, loosening the requirement for @lifetime
annotations even when the experimental LifetimeDependence mode is
enabled. Additionally, it enables this new inference rule even when the
experimental mode is disabled. All other inference rules continue to require the
experimental feature. The rule is:
If a function or method has a single inout non-Escapable parameter other than
'self' and has no other non-Escapable parameters including 'self', then infer a
single @lifetime(copy) dependency on the inout parameter from its own incoming
value.
This supports the common case in which the user of a non-Escapable type,
such as MutableSpan, wants to modify the span's contents without modifying
the span value itself. It should be possible to use MutableSpan this way
without requiring any knowledge of lifetime annotations. The tradeoff is
that it makes authoring non-Escapable types less safe. For example, a
MutableSpan method could update the underlying unsafe pointer and forget to
declare a dependence on the incoming pointer.
Disallowing other non-Escapable parameters rules out the easy mistake of
programmers attempting to trivially reassign the inout parameter. There's
is no way to rule out the possibility that they derive another
non-Escapable value from an Escapable parameteter. So users can still write
the following:
func reassign(s: inout MutableSpan<Int>, a: [Int]) {
s = a.mutableSpan
}
The 'reassign' declaration will type check, but it's implementation will
diagnose a lifetime error on 's'.
Fixes rdar://150557314 ([nonescapable] Declaration of inout MutableSpan
parameter requires LifetimeDependence experimental feature)
