Allow passing MutableSpan 'inout' without an experimental feature.

[atrick]

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)

[atrick]

@swift-ci test

[atrick]

This is also failing on main:
ModuleInterface/clang-args-transitive-availability.swift

[atrick]

@swift-ci test

[atrick]

@slavapestov @DougGregor in this commit
b71cc44

I have suppressed the extra "through reference here" diagnostic by ignoring LifetimeDependenceRequest. But I noticed that we have redundant "through reference here" notes in other cases. Does this suppression make sense or should I allow the redundant note?

[atrick]

@slavapestov @DougGregor is it acceptable to change the order of declarations in test/decl/protocols/protocols.swift?
c40fd2a

On this test, we now say protocol 'CircleMiddle' refines itself instead of protocol 'CircleStart refines itself. I don't see why one would be preferred over the other. In fact, CircleMiddle is declared first. Is this change acceptable? Simply reordering the declarations produces the original output.

protocol 'CircleMiddle' refines itself

protocol CircleMiddle : CircleStart { func circle_middle() }
// expected-note@-1 2 {{protocol 'CircleMiddle' declared here}}
protocol CircleStart : CircleEnd { func circle_start() } // expected-error 2 {{protocol 'CircleStart' refines itself}}
protocol CircleEnd : CircleMiddle { func circle_end()} // expected-note 2 {{protocol 'CircleEnd' declared here}}

Current main:

protocols.swift:7:10: error: protocol 'CircleStart' refines itself
3 | // Circular protocols
4 |
5 | protocol CircleMiddle : CircleStart { func circle_middle() }
  |          `- note: protocol 'CircleMiddle' declared here
6 | // expected-note@-1 2 {{protocol 'CircleMiddle' declared here}}
7 | protocol CircleStart : CircleEnd { func circle_start() } // expected-error 2 {{protocol 'CircleStart' refines itself}}
  |          `- error: protocol 'CircleStart' refines itself
8 | protocol CircleEnd : CircleMiddle { func circle_end()} // expected-note 2 {{protocol 'CircleEnd' declared here}}
  |          `- note: protocol 'CircleEnd' declared here

With this PR:

protocols.swift:5:10: error: protocol 'CircleMiddle' refines itself
3 | // Circular protocols
4 |
5 | protocol CircleMiddle : CircleStart { func circle_middle() }
  |          `- error: protocol 'CircleMiddle' refines itself
6 | // expected-note@-1 2 {{protocol 'CircleMiddle' declared here}}
7 | protocol CircleStart : CircleEnd { func circle_start() } // expected-error 2 {{protocol 'CircleStart' refines itself}}
  |          `- note: protocol 'CircleStart' declared here
8 | protocol CircleEnd : CircleMiddle { func circle_end()} // expected-note 2 {{protocol 'CircleEnd' declared here}}
  |          `- note: protocol 'CircleEnd' declared here
9 |

[atrick]

@meg-gupta did you run into similar problems before you guarded all the lifetime dependence type checking by the feature flag?

[DougGregor]

LGTM, thank you!

[atrick]

@swift-ci test

[atrick]

@swift-ci test

[atrick]

Unrelated linux failure

[2025-05-21T08:37:12.792Z] Unresolved Tests (1):
[2025-05-21T08:37:12.792Z]   lldb-api :: lang/swift/completion/TestSwiftREPLCompletion.py

[atrick]

@swift-ci smoke test linux