When an open class has `@_spi` designated initializers, derived classes in
clients building against its public .swiftinterface cannot safely inherit the
public convenience initializers. Print `@_hasMissingDesignatedInitializers` to
indicate this.
A similar bug for classes with designated initializers that have package access
level exists that should be fixed in a follow up. Currently, package clients
will lose access to inherited convenience inits when building from a package
.swiftinterface.
Resolves rdar://152167110
When applying a constraint system solution to a pattern binding initialization,
the type stamped onto the pattern was derived from the initializer expression
rather than from the type the solver assigned to the pattern itself. When an
explicit annotation and the initializer share a canonical type but differ in
sugar, coercing the initializer to the annotation type is a no-op that leaves
the initializer's own sugar in place, so the pattern and the VarDecl printed
into the .swiftinterface ended up with the initializer's sugar instead of the
written annotation.
This is mostly cosmetic, but it turns into a correctness problem when the
initializer's sugar names a typealias that isn't visible at the interface's
access level. For example, a public stored property annotated with a public
alias but initialized from an expression of an internal alias would print the
internal alias in the interface, producing a declaration that references a type
the interface can't see and breaking interface verification.
For typed patterns, use the pattern's solved type instead of the type derived
from the init. Assuming type checking is successful, the two types must share a
canonical type so this change only affects the printed sugar.
A better fix would be to unconditionally use the pattern's solved type,
regardless of whether the pattern is typed or not. Doing so causes some
regressions elsewhere, though, because the constraint solver does not currently
preserve typealias sugar on constructors everywhere it ought to. Using the
solved type for other kinds of patterns can therefore end up causing desugared
types to show up in more places where they aren't desirable.
Resolves rdar://178091149.
We need to ensure the right form of printName() is called, so that
associated types named "Type", "Protocol", and so on, can be
properly escaped. Otherwise, we can print something like "Self.Type"
which is interpreted as a metatype.
Fixes rdar://177052246.
The synthesized `$foo` projection variable for a property with an attached
property wrapper was not picking up any inferred availability from the wrapped
property or from the wrapper's `projectedValue`, causing some projections to be
more available than they should be. For back deployed applications that
reference the projections this could result in crashes due to missing symbols.
Resolves rdar://177839191.
The legacy, experimental SuppressedAssociatedTypes feature never
mangled any inverses into generic signatures of functions, nor mentioned
them in interfaces at all. In the new version of the feature that's been
officially accepted as SE-503, we now _do_ default primary associated
types to be Copyable & Escapable when they're suppressed. And we do mention
the suppressions in the interfaces as needed.
Rather than having the compiler mangle functions in two different ways,
this patch has the compiler be consistent about its mangling and interfaces,
regardless of which feature you're using.
This should mean that a future upgrade from the legacy feature to the
new one won't create an ABI break, only a source break (as expected).
So, an ABI change now before more people use the wrong experimental feature
will make it easier to migrate to the officially-accepted version later on.
rdar://170669869
The suppression can help us avoid a typechecking condfail,
though the mangled names of any symbols will be wrong as we simply
omit the attribute in this simplistic suppression strategy.
related to rdar://176395527
We need an alias since `@_preInverseGenerics(except: ...)` has custom parsing that older
compilers aren't designed to handle. Only simple decl attributes are parsed correctly by
older compilers, so this alias allows you to write this:
```
@_preInverseGenericsExceptCopyable
var x = 0
var x = 0
```
Which all helps with the introduction of Span<~Escapable>.
related to rdar://176395527
Follow-up to https://github.com/swiftlang/swift/pull/88733,
enabling the example in rdar://172511809 ([nonescapable] Allow a
nonescaping function to be a lifetime dependency source):
```swift
@_lifetime(body) // Inferred dependence kind: copy
func foo(body: () -> Span<Int>) { body() }
```
or
```swift
// Inferred: @_lifetime(copy body)
func foo(body: () -> Span<Int>) { body() }
```
Follow-up: Consider also disallowing borrow dependence on `@noescape`
closures.
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
---------
Co-authored-by: Andrew Trick <atrick@apple.com>
@_preInverseGenerics(except: <inverses>) is an extension of the existing
@_preInverseGenerics attribute that provides selective control over which
inverse requirements are mangled into a declaration's symbol name.
While the bare @_preInverseGenerics strips all inverse constraints
(~Copyable and ~Escapable) from mangling, the 'except:' form allows specific
inverses to be retained. This is needed when a type like Span already had
~Copyable mangled into its ABI-stable symbols and now needs to retroactively
adopt ~Escapable without changing those existing symbols. You can now express
that with `@_preInverseGenerics(except: ~Copyable)` to strip-out every inverse
except ~Copyable to preserve the pre-existing ~Copyable-containing symbols.
It requires the new experimental feature `PreInverseGenericsExcept`.
rdar://176395527
Previously, the synthesis set the access of the setter of a newly
synthesized projected value property to match that of the parent
property setter, but `projectedValue` of the property wrapper could
be less accessible than that and the synthesis needs to account
for that. Otherwise, the interface file might get a setter printed
even though it's not part of the ABI.
Resolves: rdar://176978806
Now that module selectors (SE-0491) are used by default when printing
.swiftinterface files, the following warning is unnecessary:
```
public struct <name> shadows module <name>, which may cause failures...
```
Remove the implementation of the warning entirely. Technically, we could keep
diagnosing the issue when use of module selectors in .swiftinterface files is
disabled via the `-disable-module-selectors-in-module-interface` flag, but on
balance it does not seem worth it since we don't anticipate any uses of that
flag aside from temporarily working around compiler bugs.
Resolves rdar://176476640.
If a decl written in source has `override` because it overrides a `package`
decl, then the `override` keyword should be printed in the
`.package.swiftinterface` since the overridden decl is visible.
Resolves rdar://158178648.
Add test cases for various edge cases related to conformances with
MemberImportVisibility enabled. Missing imports that break conformances should
be diagnosed, but those diagnostics should not prevent certain accepted
conformances from continuing to be accepted.
Tests only, NFC.
The @diagnose attribute only affects local diagnostic behavior within a declaration's body and has no API or ABI impact. It should not appear in .swiftinterface files, and should not cause declarations to be wrapped in #if $SourceWarningControl feature guards.
When a requirement witnesses itself that indicates that no witness was found
and the conformance checker is treating the witness as "opaque". The visibility
of the requirement should not be diagnosed.
Follow up to https://github.com/swiftlang/swift/pull/88616.
Resolves rdar://175691719.
Conformance checking in swiftinterfaces is lenient and can recover from missing
witnesses by assuming that the protocol witness table will have an entry for
the requirement at runtime. As a result, diagnosing missing imports for
witnesses here could break source compatibility for existing interface files
and must be skipped. This fixes a regression introduced by
https://github.com/swiftlang/swift/pull/88470.
Resolves rdar://175215763.
Makes it possible for users of `-warnings-as-errors` to control the behavior of
warnings about the obsoletion of module interface emission options.
Resolves rdar://174787052.
The `@export(interface)` and `@export(implementation)` attributes
SE-0497 are queried directly on AST nodes in several places within the
SIL pipeline. However, they don't persist when SIL functions are
serialized, meaning that clients of the original module might make
different assumptions about the availability of a given function's
definition.
Represent these attributes in a SIL function (as an optional
CodeGenerationModel), (de-)serialize them into the module, and add a
textual representation as SIL function attributes `[export_interface]`
and `[export_implementation]`.
Back in January, I updated the swiftinterface _reading_ code to accept either
`read`/`modify` or `yielding borrow`/`yielding mutate`. That update has been
around for long enough that we can now switch over the swiftinterface _writing_
code to emit the standard final `yielding borrow`/`yielding mutate` spellings.
Interface files written with the old spellings will continue to be
accepted for some time (likely a year or more).
The only known condfail scenario is inheriting from
a protocol P that inherits from a reparentable one R.
We already guard P if it mentions R in its inheritance clause.
So older compilers will simply report that "P" is missing in the
interface, which is a better error message than virally guarding
everything mentioning P. It's an ABI break anyway to do that
without introducing a `@reparented` extension, which needs a guard.
In theory, older compilers shouldn't have too much go wrong if they
were to ignore `@reparentable`, though the RequirementMachine and
witness tables will look different.
rdar://174263176
As a follow up to https://github.com/swiftlang/swift/pull/87832, continue
adjusting the algorithm for computing synthesized conformance availability.
When an outer declaration is `unavailable` in a more specific platform domain
and the inner declaration is `introduced:` in a less specific domain, the inner
declaration attribute does not override the outer declaration attribute.
Unavailability and introduction on separate axes of availability.
Resolves rdar://173724423.
The compiler synthesizes an `unownedExecutor` property for every `actor` type.
It was also synthesizing availability attributes for this property by
intersecting the availability of the actor type and the `UnownedExecutor` type.
This may have been necessary early in the development of Swift Concurrency but
now it amounts to little more than a convoluted procedure that must result in
repeating the availability of the actor on one of its properties (the property
can never be less available than the actor itself).
When printing `.swiftinterface` files, implicit conformances may need to be
printed with inferred availability attributes. The existing algorithm for
determining which availability attributes to print needed a few updates to
better handle `anyAppleOS` availability attributes:
- `@available(anyAppleOS, ...)` attributes attached to a nested declaration
should take priority over platform-specific `@available` attributes on outer
declarations.
- At the same time, `@available(anyAppleOS, ...)` attributes attached to the
_same_ declaration as a platform-specific `@available` attribute should not
take priority. Instead, both attributes should be included in the inferred
set.
Default to use new swift-driver to run lit tests as legacy swift driver
is deprecated for a long time. The lit tests for legacy drivers are also
disable when running new swift-driver.
Tests that relies on legacy swift driver (for example, tests merge
module) can be enabled on conditions `legacy_swift_driver`. Fix and
split up some existing tests that relies on legacy driver.
Allan Shortlidge
Tony Allevato
Slava Pestov
Kavon Farvardin
Tony Allevato
Aidan Hall
Dario Rexin
Pavel Yaskevich
Pavel Yaskevich
Artem Chikin
Aidan Hall
Tim Kientzle
Doug Gregor
Saleem Abdulrasool
Meghana Gupta
Meghana Gupta
Steven Wu