If we fail to resolve the value type for a value generic parameter,
previously we would have returned a null Type, causing crashes
downstream. Instead, return an ErrorType, leaving a null Type for
cases where the generic parameter isn't a value generic at all.
rdar://154856417
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)
Users commonly try to write a lifetime dependency on an 'inout' parameters as:
@_lifetime(a: &a)
func f_inout_useless(a: inout MutableRawSpan) {}
This is useless. Guide them toward what they really wanted:
@_lifetime(a: copy a)
Fixes rdar://151618856 (@lifetime(..) gives inconsistent error messages)
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.
If two conformances imply a conformance to the same marker
protocol, don't diagnose redundancy if they differ by
unavailability. Instead, allow the more available conformance
to win.
This allows declaring a type that conforms to a protocol
that inherits from SendableMetatype, followed by an
unavailable Sendable conformance on the same type.
Fixes rdar://152509409.
This logic was introduced in https://github.com/swiftlang/swift/pull/75135.
The intent was to prevent an implied conformance from overriding an
existing unavailable one, for example in the case of Sendable. Let's
relax this check a bit to only diagnose if the mismatch is in the
unconditional availability, and not OS version.
Fixes rdar://142873265.
This fixes a small oversight in the type checker's LifetimeDependence
inference. Allow inference on _read accessors even when 'self' is a trivial
type. This is needed because the compiler synthesizes a _read accessor even when
the user defines a getter (this is probably a mistake, but it's easire to just
fix inference at this point). There is no workaround because it defining both a
getter and '_read' is illegal!
extension UnsafeMutableRawBufferPointer {
var mutableBytes: MutableRawSpan {
@_lifetime(borrow self)
get {
unsafe MutableRawSpan(_unsafeBytes: self)
}
}
}
Fixes rdar://153346478 (Can't compile the
UnsafeMutableRawBufferPointer.mutableBytes property)
I previously added this hack to match the logic in
`TypeChecker::lookupUnqualified`, but it turns out that can introduce
request cycles for cases where `CodingKeys` is used in a generic
requirement for one of `Codable`'s potential value witnesses. Scale
back the hack such that it's only done when we get an initial empty
lookup result, ensuring we maintain source compatibility. Both these
lookup hacks should go away once we properly handle CodingKeys
synthesis.
rdar://153096639
When the CustomAvailability experimental feature is enabled, make it an error
to specify an unrecognized availability domain name. Also, add these
diagnostics to a diagnostic group so that developers can control their behavior
when they are warnings.
Resolves rdar://152741624.
This matches send non sendable but importantly also makes it clear that we are
talking about something that doesn't conform to the Sendable protocol which is
capitalized.
rdar://151802975
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'")
