`LifetimeDescriptor::getName()` can crash if the descriptor had a `self`.
Replace with `LifetimeDescriptor::getString()`
(cherry picked from commit 6d0a6d2760)
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
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)
(cherry picked from commit 87f2510a27)
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))
(cherry picked from commit 080b68292d)
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) {}
(cherry picked from commit 05fa82b7a7)
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.
(cherry picked from commit df0b81c88d)
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)
(cherry picked from commit 8789a686fed869e3cd7bc4e748a443e71df464e1)
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)
(cherry picked from commit 125a0862a9)
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
(cherry picked from commit 3ed4059a60)
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'")
(cherry picked from commit 6cc1a8d880)
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)
(cherry picked from commit dbcba013434aeaa042e9f5cc9ec0829d762b74e0)
Enhance the logic in `applyInverses` to also take into account same-type constraints spelled in
the generic signature, so that same-type-constraining a type parameter to a type that is itself
not `Copyable` or `Escapable` suppresses the default application of those constraints on the
type parameter. Fixes rdar://147757973.
Cherry-pick of #80547 for the 6.2 release branch.
---
Explanation: This cherry picks the implementation of SE-0477 to add a
string interpolation method with a `default:` parameter for optional
interpolation values.
Main Branch PR: https://github.com/swiftlang/swift/pull/80547
Risk: Low.
Reviewed By: @stephentyrone
Resolves: rdar://150865613
Testing: New tests for the string interpolations and fix-its.
With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
(cherry picked from commit 46c394788a84d5932289c71274dd32ea2d61d9dc)
We can always get it back from the git history.
rdar://150695113
(cherry picked from commit 9d59dbed17)
Conflicts:
include/swift/AST/DiagnosticsSema.def
include/swift/Basic/Features.def
test/abi/macOS/arm64/concurrency.swift
test/abi/macOS/x86_64/concurrency.swift
Operator function parsing has a heuristics to determine if `<` a part of
the operator name or the generic parameter clause. Handle `let` there
because value generics uses it.
rdar://149556573
(cherry picked from commit 682d2634ba)
When the type checker diagnoses an error on an implicit initializer,
return immediately before handling its parameter to avoid an assert.
(cherry picked from commit e9ac803e94)
In strict concurrency mode some calls could reference a declaration that
is wrapped in one or more function conversion expressions to apply
concurrency related attributes or erase them (such as `@Sendable` or
`@MainActor`). This shouldn't impact constness checking and the checker
should look through such conversions.
Resolves: rdar://148168219
(cherry picked from commit b484e9645d)
