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
Changes the diagnostics emitted when an `@objc @implementation` extension is missing some of the members required by the extension:
• We now emit one error on the extension, plus a note for each missing member.
• Where possible, we also emit a note with a fix-it adding stubs.
For example:
```
9 | @objc @implementation extension ObjCClass {
| |- error: extension for main class interface does not provide all required implementations
| |- note: missing instance method 'method(fromHeader3:)'
| |- note: missing instance method 'method(fromHeader4:)'
| |- note: missing property 'propertyFromHeader7'
| |- note: missing property 'propertyFromHeader8'
| |- note: missing property 'propertyFromHeader9'
| |- note: missing instance method 'extensionMethod(fromHeader2:)'
| `- note: add stubs for missing '@implementation' requirements
```
With a fix-it on the last note to insert the following after the open brace:
```
@objc(methodFromHeader3:)
open func method(fromHeader3 param: Int32) {
<#code#>
}
@objc(methodFromHeader4:)
open func method(fromHeader4 param: Int32) {
<#code#>
}
@objc(propertyFromHeader7)
open var propertyFromHeader7: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(propertyFromHeader8)
open var propertyFromHeader8: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(propertyFromHeader9)
open var propertyFromHeader9: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(extensionMethodFromHeader2:)
open func extensionMethod(fromHeader2 param: Int32) {
<#code#>
}
```
Fixes rdar://130038221.
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
This attribute controls whether cross-module access to the declaration
needs `@unknown default:` because it's allowed to gain new cases even
if the module is non-resilient.
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.
