Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
We are likely to debugging more cyclic references involving macros in
the future, so improve the diagnostics to specify what operation we're
performing (e.g., macro resolution vs. expansion of a particular kind
of macro) and the macro name, when possible, so failures are easier to
diagnose. No functionality change for well-formed code.
Issue a deprecation warning in Swift 5 and an error in Swift 6 when we encounter @UIApplicationMain and @NSApplicationMain. These attributes are unnecessary now that @main works with UIApplicationDelegate and NSApplicationDelegate. As these conformances are required when working with the corresponding attributes, we can migrate users off of them by replacing them with @main.
Marking a stored property as unavailable with `@available` should be banned,
just like it already is banned for potential unavailability. Unavailable code
is not supposed be reachable at runtime, but unavailable properties with
storage create a back door into executing arbitrary unavailable code at
runtime:
```
@available(*, unavailable)
struct Unavailable {
init() {
print("Unavailable.init()")
}
}
struct S {
@available(*, unavailable)
var x = Unavailable()
}
_ = S() // prints "Unavailable.init()"
```
Resolves rdar://107449845
Destructors are always called if declared, so allowing deinit to be declared as
unavailable (or potentially unavailable) creates a type checking loophole that
allows unavailable code to execute at runtime:
```
class C {
@available(*, unavailable)
deinit {
print("Oops")
}
}
_ = C() // prints "Oops"
```
Resolves rdar://106409012 and https://github.com/apple/swift/issues/63854.
In preparation for supporting macros that are defined in terms of other
macros, adopt macro definition checking provided by the
`MacroDeclSyntax.checkDefinition` operation (implemented in
swift-syntax). Use this in lieu of the checking on the C++ side.
This required me to finally fix an issue with the source ranges for
Fix-Its, where we were replacing the leading/trailing trivia of nodes
along with the node itself, even though that's incorrect: we should
only replce the node itself, and there are other Fix-It kinds for
replacing leading or trailing trivia.
SE-0382 allows macro parameters to have default arguments. Enable these
default arguments, with the normal type checking rules. One
significant quirk to this implementation is that the actual default
argument values don't make it to the macro implementation. This is a
previously-unconsidered design problem we'll need to address.
Tracked by rdar://104043987.
Create a checker for @_objcImplementation member implementations that considers all of a class’s interface and implementation decls at once. This allows us to handle several things better:
• Unimplemented requirements are now diagnosed
• Header members that can match several implementations, or implementations that could match several header members, are now diagnosed
• Tailored diagnostic when the implementation's Swift name matches the header's selector instead of its Swift name
• Recommends inserting `@objc(<selector>)` when a Swift name matches but the implicit ObjC name doesn't
• An `@objc(<selector>)` on one implementation can eliminate its requirement from being considered for other implementations, resolving ambiguities
This does unfortunately regress the diagnostics when a requirement is implemented in the wrong extension. Some sort of whole-module checking would be needed to address this problem.
• `@objc` is now inferred on non-`final` members of @objcImplementation extensions
• Diagnostics now suggest adding `private` to ObjC helper members, not `@objc`, in line with currently proposed behavior
• Better diagnostic for members implemented in the wrong extension
Part of rdar://103150189.
It turns out that we must allow declarations with `introduced:` availability
nested inside of other declarations that are `unavailable` in order to
influence weak linking. Stop diagnosing declarations as being more available
than their unavailable containers and revert some changes to availability
inference that were designed to avoid creating these nestings but caused
regressions for declarations marked `@_spi_available.`
Reverts parts of https://github.com/apple/swift/pull/64310,
https://github.com/apple/swift/pull/64015, and
https://github.com/apple/swift/pull/62900.
