The present approach is not prudent because `@concurrent` synchronous
functions, a natural extension, are a likely-to-happen future direction,
whereas the current inference rule is entirely grounded on `@concurrent`
being exclusive to async functions.
If we were to ship this rule, we would have to keep the promise for
backwards compatibility when implementing the aforementioned future
direction, replacing one inconsistency with another, and possibly
introducing new bug-prone expression checking code.
```swift
func foo(_: () -> Void) {}
func foo(_: () async -> Void) {}
// In a future without this change and `@concurrent` synchronous
// functions accepted, the first call resolves to the first overload,
// and the second call resolves to the second, despite `@concurrent` no
// longer implying `async`.
foo { }
foo { @concurrent in }
```
This change also drops the fix-it for removing `@concurrent` when used
on a synchronous closure. With the inference rule gone, and the
diagnosis delayed until after solution application, this error raises a
fairly balanced choice between removing the attribute and being
explicit about the effect, where a unilateral suggestion is quite
possibly more harmful than useful.
(cherry picked from commit 58d5059617)
Fixes a crash on invalid. The previous logic was causing a label
mismatch constraint fix to be recorded for an unlabeled trailing closure
argument matching a variadic paramater after a late recovery argument
claim in `matchCallArgumentsImpl`, because the recovery claiming skips
arguments matching defaulted parameters, but not variadic ones. We may
want to reconsider that last part, but currently it regresses the
quality of some diagnostics, and this is a targeted fix.
The previous behavior is fine because the diagnosis routine associate
with the constraint fix (`diagnoseArgumentLabelError`) skips unlabeled
trailing closures when tallying labeling issues — *unless* there are no
other issues and the tally is zero, which we assert it is not.
Fixes rdar://152313388.
(cherry picked from commit f2e1420a90)
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
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.
Several callers of `AbstractStorageDecl::getAccessStrategy` only cared
about whether the the access would be via physical storage. Before
adding more arguments to `getAccessStrategy` for which such callers
would have to pass a sentinel value, add a convenience method for this.
Rather than representing a missing availability range on `PoundAvailableInfo`
with a default-constructed `AvailabilityRange` (empty), store the ranges as
optionals instead. This allows an empty range to represent an availability
condition which is known to be false at compile time, which will be necessary
when generating SIL for `if #available` queries that check custom availability
domains.
`AvailabilityRange` is now being used as a currency type in more of the
compiler, and some of those uses are in permanent `ASTContext` allocations. The
class wraps the `VersionRange` utility, which is itself a wrapper around
`llvm::VersionTuple` with some additional storage for representing sentinel
values. Even though the two sentinel values can be be represented with just a
single bit of additional storage on top of the 16 bytes required to represent
`VersionTuple`, because of alignment requirements the sentinel values end up
bloating the layout of `VersionRange` by many bytes.
To make `AvailabilityRange` and `VersionRange` more efficient to store, we can
instead reserve two unlikely `llvm::VersionTuple` bit patterns as the sentinel
values instead. The values chosen are the same ones LLVM uses to represent
version tuple tombstones and empty keys in a `DenseMap`.
This simplifies the code to emit availabilty diagnostics and ensures that they
display domain names consistently. While updating existing diagnostics, improve
consistency along other dimensions as well.
Delay resolution of availability domain identifiers parsed in availability
specifications until type-checking. This allows custom domain specifications to
be written in `if #available` queries.
In order to unblock resolution of availability domains during type-checking
instead of parsing, diagnostics about missing or superfluous wildcards in
availability specification lists need to move to Sema.
It wraps an type-checked `AvailabilitySpec`, which guarantees that the spec has
a valid `AvailabilityDomain` associated with it. This will unblock moving
AvailabilitySpec domain resolution from parsing to sema.
Eventually, querying the `AvailabilityDomain` associated with an
`AvailabilitySpec` will require invoking a request that takes a `DeclContext`.
This means that any diagnostics related to the domain identified by an
`AvailabilitySpec` need to be emitted during type-checking rather than parsing.
This change migrates several `AvailabilitySpec` diagnostics from Parse to Sema
to unblock further work.
We previously missed diagnosing this for macro
args, fixing it turned out to be a bit more source
breaking than initially thought though, so downgrade
to a warning until Swift 7.
rdar://141963700
When iterator consists of tuple of variable and iteration only mutates
the tuple partially, improve the warning message from "changing to 'let"
to "changing the pattern to '(..., case let, ...)"
Previously we would check if we have a SwitchStmt,
and apply diagnostics such as `checkExistentialTypes`
to the CaseStmts individually. This however would
have been missed for `catch` statements. The change
to consistently call `performStmtDiagnostics` in
closures fixed this for `do-catch`'s in closures,
this commit fixes it for those outside of closures.
Because this is source breaking, the existential
diagnostic is downgraded to a warning until Swift
7 for catch statements specifically.
While here, also apply the ambiguous where clause
diagnostic to `catch` statements.
Really this applies to any capture, not just
`self`. Also refactor to make it clear that
parent closures and functions are really the only
cases that matter here.
Opaque type metadata accessor functions could be miscompiled for functions that
contain `if #available` checks for inactive platforms. For example, this
function will always return `A` when compiled for macOS, but the opaque type
accessor would instead return the type metadata for `B`:
```
func f() -> some P {
if #available(iOS 99, *) {
return A() // Returns an A on macOS
} else {
return B()
}
}
```
Resolves rdar://139487970.
It doesn't make sense to use `VersionRange::empty()` to represent "universally
available" since something that is available in an empty version range is
effectively never available.
When a protocol which has a read (or modify) requirement is built with
the CoroutineAccessors feature, it gains a read2 (or modify2,
respectively) requirement. For this to be compatible with binaries
built without the feature, a default implementation for these new
requirements must be provided. Cause these new accessor requirements to
have default implementations by returning `true` from
`doesAccessorHaveBody` when the context is a `ProtocolDecl` and the
relevant availability check passes.
C++ swift::Parser is going to be replaced with SwiftParser+ASTGen.
Direct dependencies to it should be removed. Before that, remove
unnecessary '#include "swift/Parse/Parser.h"' to clarify what actually
depends on 'swift::Parser'.
Split 'swift::parseDeclName()' et al. into the dedicated files.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
