It has been decided to split the attribute into `@concurrent` and
`nonisolated(nonsending`. Adjusting diagnostics to accept the attribute
makes the transition easier.
This implements basic checks on the validity of the @cdecl attribute and
ensures the parameters and result types are representable in C. Many
more diagnostics will need to be updated to verify full representability
in C.
This should be a no-op for operators today expect that we found
a case were C++ imported operator that had a label for the second
argument which disabled the overload choice early and attempted
to disable it again here which breaks CSTrail because pruned
choices are re-enabled once disjunction checking is complete.
The original check examined only the immediate closure, but it's
possible that the closure happens to be in a preconcurrency context
which also requires a downgrade.
Resolves: rdar://148996589
When generating a stub fix-it for a protocol conformance or implementation extension, Swift will now evaluate whether the context allows the declaration of stored properties and, if so, will suggest one. It will also use the `let` keyword instead of `var` if the property has no setter.
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.
