It has been decided to split the attribute into `@concurrent` and
`nonisolated(nonsending`. Adjusting diagnostics to accept the attribute
makes the transition easier.
The introduction of non-Sendable metatypes in Swift 6.2 (via SE-0470)
will break some existing Swift 6 code. Downgrade concurrency errors
involving non-Sendable metatypes to warnings until some future
language mode to ease the transition.
(cherry picked from commit 95b18d3482)
The code that determines whether a reference to a static method (that
is not a call) assumed that metatypes were always Sendable. This is no
longer the case, so update this code to go through the normal Sendable
checking on the metatype.
(cherry picked from commit 3ed1d6c390)
The IsolatedConformances feature moves to a normal, supported feature.
Remove all of the experimental-feature flags on test cases and such.
The InferIsolatedConformances feature moves to an upcoming feature for
Swift 7. This should become an adoptable feature, adding "nonisolated"
where needed.
(cherry picked from commit 3380331e7e)
This is going to need a proper implementation in the requirement
machine. For the moment, provide a slightly-less-broken implementation
but leave a test case where we incorrectly accept racey code.
(cherry picked from commit 92774e0a3c)
Kicking the interface type request of the base decl here is wrong
if the decl is e.g a `self` capture in a closure, since we'll be in
the middle of type-checking the closure. I'm planning on properly
fixing this by folding the lookup into the constraint system, but for
now let's at least avoid kicking the request if we don't have an enum
case or enum var. That at least prevents it from affecting cases where
e.g you're pattern matching against a property in a class.
We could potentially tighten up the checking here even further, but
that could potentially impact source compatibility for ambiguous
cases. I'd like to keep this patch low risk, and then deal with any
fallout as part of the pattern type-checking work.
rdar://146952007
Extensions that extend non-public types should never be required to have
explicit availability, even if they declare conformances to public protocols.
Resolves rdar://148697770.
Previously we would avoid rewriting the arguments in CSApply, but
that can result in incorrect behavior in MiscDiagnostics passes, e.g
incorrectly treating all closure arguments as escaping. Make sure
we rewrite the arguments as we would in regular type-checking.
rdar://148665502
Introduce `PatternBindingCaptureInfoRequest`, and kick it after
contextualizing a property initializer. This ensures it gets run
for stored properties added by macro expansions.
rdar://143429551
We have a special hack to infer the 'Failure' type witness in
'AsyncIteratorProtocol' by considering the type of 'next()'
witness.
In eaf06eae0e I added a check to
fix some assertions that could happen if 'next()' was witnessed
by a declaration in a protocol extension or superclass, which
has a different generic signature.
However my check was too narrow, because it also prohibited
this form of inference when 'next()' was in a different
extension of the same nominal type.
Allow this again.
Fixes https://github.com/swiftlang/swift/issues/79367.
Fixes rdar://problem/145341658.
The changes in https://github.com/swiftlang/swift/pull/80040 caused the
compiler to start diagnosing extensions containing only members that are
either `@_spi`, `@_alwaysEmitIntoClient`, or unavailable when the
`-require-explicit-availability` flag is passed. Extensions should not be
diagnosed when they only contain members that would not be diagnosed
themselves.
Resolves rdar://148275432.
When a generic function has potentially Escapable outputs, those outputs
declare lifetime dependencies, which have no effect when substitution
leads to those types becoming `Escapable` in a concrete context.
This means that type substitution should canonically eliminate lifetime
dependencies targeting Escapable parameters or returns, and that
type checking should allow a function value with potentially-Escapable
lifetime dependencies to bind to a function type without those dependencies
when the target of the dependencies is Escapable.
Fixes rdar://147533059.
The following warning was being emitted by newer versions of clang:
```
comparisons like 'X<=Y<=Z' don't have their mathematical meaning [-Wparentheses]
```
This code needs to be reworked to ensure that the conditions that are meant to
be asserted are true.
Witness matching didn't handle the case where either the
requirement or the witness is a property with a throwing
getter, and the thrown error type contains a type parameter.
We must open the thrown error types first, replacing type
parameters with type variables, for the matching to work.
Associated type inference needs a similar fix. I'll land a
combined test case for both once I fix that.
Fixes https://github.com/swiftlang/swift/issues/80288.
Fixes rdar://problem/147874955.
Additional restrictions on when protocol inference could be considered
viable. If the chain is connected directly to a contextual type there
cannot be any other inference sources for the base type.
Resolves: rdar://148256978
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.
The `-require-explicit-availability` compiler flag is designed to help
developers find declarations that they've written with missing availability.
The flag is not printed in swiftinterface files, though, so if a module has
both `-library-level=api` and also has `-require-explicity-availability=ignore`
(as the Swift stdlib does) then the result is that superfluous diagnostics are
emitted when typechecking the emitted module interface that should have been
suppressed by the `ignore` flag. Suppress these diagnostics when typechecking
swiftinterface files since they are only designed to be seen by the owner of
the module when they are building the module from source and they don't have
much value in the context of interface verification.
Arguments that were already pack expansions were being wrapped in a
second layer--preventing some would-be unambiguous overloads from
resolving. This adds a check to avoid doing that.
