Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Instead of diagnosing in CSApply, let's create a
fix and diagnose in the solver instead.
Additionally, make sure we assign ErrorTypes to
any VarDecls bound by the invalid pattern, which
fixes a crash.
rdar://110638279
Diagnose situations where value pack is referenced without an explicit 'each':
```
func compute<each T>(_: repeat each T) {}
func test<each T>(v: repeat each T) {
repeat compute(v) // should be `repeat compute(each v)`
}
```
Diagnose situation when a single argument to tuple type is passed to
a value pack expansion parameter that expects distinct N elements:
```swift
struct S<each T> {
func test(x: Int, _: repeat each T) {}
}
S<Int, String>().test(x: 42, (2, "b"))
```
Just like in any other position, let's restore unresolved type variables
that represent generic parameters to their generic parameter type when
they are found in a pack expansion pattern type.
Since values of generic type are currently assumed to always
support copying, we need to prevent move-only types from
being substituted for generic type parameters.
This approach leans on a `_Copyable` marker protocol to which
all generic type parameters implicitly must conform.
A few other changes in this initial implementation:
- Now every concrete type that can conform to Copyable will do so. This fixes issues with conforming to a protocol that requires Copyable.
- Narrowly ban writing a concrete type `[T]` when `T` is move-only.
associated failure diagnostic.
This constraint fix is unused now that MacroExpansionExpr always has an
argument list, and goes through the AddMissingArguments constraint fix for
this error.
Rather than re-using `DiagnosticBehavior` to describe how a fix should
act, introduce `FixBehavior` to cover the differences between (e.g.)
always-as-awarning and downgrade-to-warning. While here, split the
`isWarning` predicate into two different predicates:
* `canApplySolution`: Whether we can still apply a solution when it
contains this particular fix.
* `affectsSolutionScore`: Whether
These two predicates are currently tied together, because that's the
existing behavior, but we don't necessarily want them to stay that way.
Instead of the `warning` Boolean threaded through the solver's
diagnostics, thread `DiagnosticBehavior` to be used as the behavior
limit. Use this for concurrency checking (specifically dropped
`@Sendable` and dropped global actors) so the solver gets more control
over these diagnostics.
This change restores the diagnostics to a usable state after the prior
change, which introduced extra noise. The only change from existing
beavior is that dropping a global actor from a function type is now
always a warning in Swift < 6. This is partly intentional, because
there are some places where dropping the global actor is well-formed.
For code such as the following:
```
let r = Regex {
/abc/
}
```
If RegexBuilder has not been imported, emit a
specialized diagnostic and fix-it to add
`import RegexBuilder` to the file.
Unfortunately we're currently prevented from
emitting the specialized diagnostic in cases where
the builder contains references to RegexBuilder
types, such as:
```
let r = Regex {
Capture {
/abc/
}
}
```
This is due to the fact that we bail from CSGen
due to the reference to `Capture` being turned
into an `ErrorExpr`. We ought to be able to
handle solving in the presence of such errors, but
for now I'm leaving it as future work.
rdar://93176036
Diagnose situations where pattern variables with the same name
have conflicting types:
```swift
enum E {
case a(Int)
case b(String)
}
func test(e: E) {
switch e {
case .a(let x), .b(let x): ...
}
}
```
In this example `x` is bound to `Int` and `String` at the same
time which is incorrect.
If erased result is passed as an argument to a call that requires
implicit opening, the fix-it should use parens to avoid suppressing
the opening at that argument position.
Diagnose situations where inferring existential type for result of
a call would result in loss of generic requirements.
```swift
protocol P {
associatedtype A
}
protocol Q {
associatedtype B: P where B.A == Int
}
func getB<T: Q>(_: T) -> T.B { ... }
func test(v: any Q) {
let _ = getB(v) // <- produces `any P` which looses A == Int
}
```
