Non-escapable struct definitions often have inicidental integer fields that are
unrelated to lifetime. Without an explicit initializer, the compiler would infer
these fields to be borrowed by the implicit intializer.
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
/* infer: @lifetime(copy span, borrow i) init(...) */
}
This was done because
- we always want to infer lifetimes of synthesized code if possible
- inferring a borrow dependence is always conservative
But this was the wrong decision because it inevitabely results in lifetime
diagnostic errors elsewhere in the code that can't be tracked down at the use
site:
let span = CountedSpan(span: span, i: 3) // ERROR: span depends on the lifetime of this value
Instead, force the author of the data type to specify whether the type actually
depends on trivial fields or not. Such as:
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
@lifetime(copy span) init(...) { ... }
}
This fix enables stricter diagnostics, so we need it in 6.2.
Fixes rdar://152130977 ([nonescapable] confusing diagnostic message when a
synthesized initializer generates dependence on an Int parameter)
This is a common mistake made more common be suggestions of existing diagnostic
that tell users not to use a 'copy' dependency.
Report a diagnostic error rather than crashing the compiler. Fix the diagnostic
output to make sense relative to the source location.
Fixes rdar://154136015 ([nonescapable] compiler assertion with @_lifetime(x: inout x))
Correctly diagnose this as:
"invalid use of inout dependence on the same inout parameter
@_lifetime(a: &a)
func f_inout_useless(a: inout MutableRawSpan) {}
Correctly diagnose this as:
"lifetime-dependent parameter must be 'inout'":
@_lifetime(a: borrow a)
func f_inout_useless(a: borrowing MutableRawSpan) {}
This comes up often when passing a MutableSpan as an 'inout' argument. The
vague diagnostic was causing developers to attempt incorrect @_lifetime
annotations. Be clear about why the annotation is needed and which annotation
should be used.
'@preconcurrency' imports open up memory safety holes with respect to
Sendable, which are diagnosed under strict memory safety + strict
concurrency checking. Allow one to write '@unsafe' on those imports to
silence the diagnostic about it.
While this made sense in the distant past where the scanning service provided backing storage for the dependency cache, it no longer does so and now makes for awkard layering where clients get at the service via the cache. Now the cache is a simple data structure while all the clients that need access to the scanning service will get it explicitly.
- 'SwiftModuleScanner' will now be owned directly by the 'ModuleDependencyScanningWorker' and will contain all the necessary custom logic, instead of being instantiated by the module interface loader for each query
- Moves ownership over module output path and sdk module output path directly into the scanning worker, instead of the cache
To guard the new UnsafeMutablePointer.mutableSpan APIs.
This allows older compilers to ignore the new APIs. Otherwise, the type checker
will crash on the synthesized _read accessor for a non-Escapable type:
error: cannot infer lifetime dependence on the '_read' accessor because 'self'
is BitwiseCopyable, specify '@lifetime(borrow self)'
I don't know why the _read is synthesized in these cases, but apparently it's
always been that way.
Fixes: rdar://153773093 ([nonescapable] add a compiler feature to guard
~Escapable accessors when self is trivial)
