We parse `~Copyable` in an inheritance clause of enum and
struct decls as a synonym for the `@_moveOnly` attribute
being added to that decl. This completely side-steps the
additional infrastructure for generalized suppressed
conformances in favor of a minimal solution. One benefit of
this minimal solution is that it doesn't risk introducing
any back-compat issues with older compilers or stdlibs.
The trade-off is that we're more committed to supporting
`@_moveOnly` in compiled modules in the future. In fact,
this change does not deprecate `@_moveOnly` in any way.
resolves rdar://106775103
Some decls that are expected to be synthesized for distributed actors are
printed explicitly in swiftinterfaces so diagnostics and assertions need to
take that possibility into account.
Resolves rdar://108533918
Parse compound and special names in the macro role attributes
(`@freestanding` and `@attached`). This allows both compound names and
initializers, e.g., `init(coding:)`.
Fixes rdar://107967344.
Relax the diagnostics for the `@exclusivity` attribute in order to avoid type
checking failures for `public private(set)` properties in resilient libraries.
In a `swiftinterface` it's not possible to tell reliably whether a property has
storage.
Resolves rdar://107770440
The main issue was that the tests specified `-library-level=api` in
`swift-frontend` invocations instead of `-library-level api`. The former seems
to have no effect and therefore expected diagnostics were not being emitted.
Additional clean up:
- Make every test require `OS=macosx` for ease of local testing.
- Avoid unnecessarily specifying target arches (this makes tests slow).
- Add missing `FileCheck` invocation.
- Add some missing test coverage.
Resolves rdar://91325474
* [ModuleInterface] Guard layout based prespecializations in swiftinterface files
rdar://107269447
To allow compilers that don't have this feature enabled to parse interface files that contain declarations that use layout based prespecializations, it has to be guarded.
* Incorporate feedback
Switch the ModuleInterface/objc_implementation.swift test to using standard substitutions to properly emit its module interface, and make sure it also verifies.
When writing an @objc subclass of an @objcImplementation class, implicit initializers in the subclass were treated as overriding the *implementation decl*, not the *interface decl*, of the initializer in the superclass. This caused Swift to incorrectly compute the visibility of the superclass initializer and omit an `override` keyword from the module interface when one would definitely be necessary.
Correct this oversight by looking up the interface decl matching the superclass implementation in `collectNonOveriddenSuperclassInits()`.
Module interfaces should not include the @objcImplementation attribute, member implementations that are redundant with the ObjC header, or anything that would be invalid in an ordinary extension (e.g. overridden initializers, stored Swift-only properties).
I enabled move-only types by default, but I didn't
realize that the `Feature::MoveOnly` needs to graduate
into a `LANGUAGE_FEATURE` so that `EvaluateIfConfigCondition`
will recognize `$MoveOnly` as being true.
fixes rdar://107050387
In https://github.com/apple/swift/pull/63898 conformance requirement
typechecking was relaxed to allow unavailable decls to witness conformance
requirements as long as the conforming nominal was also unavailable. However,
only nominals that were directly marked unavailable were accepted. Nominals
that are declared in unavailable scopes should also be allowed to have
unavailable wintesses.
Resolves rdar://107052715
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.
the main things still left behind the experimental flag(s) are
- move-only classes (guarded by MoveOnlyClasses feature)
- noimplicitcopy
- the _borrow operator
Previously, when creating availability attributes for synthesized declarations
we would identify some set of reference declarations that the synthesized
declaration should be as-available-as. The availability attributes of the
reference declarations would then be merged together to create the attributes
for the synthesized declaration. The problem with this approach is that the
reference declarations themselves may implicitly inherit availability from their
enclosing scopes, so the resulting merged attributes could be incomplete. The
fix is to walk though the enclosing scopes of the reference declarations,
merging the availability attributes found at each level.
Additionally, the merging algorithm that produces inferred availability
attributes failed to deal with conflicts between platform specific and platform
agnostic availability. Now the merging algorithm notices when platform agnostic
availability should take precedence and avoids generating conflicting platform
specific attributes.
Resolves rdar://106575142
Previously, implicit imports were also being added to the module interface during override checking (without any diagnostic).
Additionally, correct the structure of the import which contained an extra, duplicated path component. It would be diagnosed as a scoped import and written into the interface like this:
```
import UIKit/*.UIKit*/
```
Resolves rdar://104935794
The _Copyable constraint was implemented as a marker protocol.
That protocol is part of the KnownProtocol's in the compiler.
When `ASTContext::getProtocol(KnownProtocolKind kind)` tries
to find the ProtocolDecl for Copyable, it will look in the
stdlib module (i.e., Swift module), which is where I initially
planned to put it.
That created problems initially when some regression tests
use `-parse-stdlib` failed to do that protocol lookup, which is
essential for adding the constraint (given the current implementation).
That led to believe we need to pull Copyable out of the stdlib, but that's
wrong. In fact, when building the Swift module itself, we do `-parse-stdlib`
but we also include `-module-name Swift`. This causes the _Copyable protocol
defined in the Stdlib to be correctly discovered while building the stdlib
itself (see the test case in this commit). So, the only downside of
having the Copyable protocol in the Stdlib is that `-parse-stdlib` tests
in the compiler can't use move-only types correctly, as they'll be
allowed in generic contexts. No real program would build like this.
Until I have time to do a further refactoring, this is an acceptable trade-off.
fixes rdar://104898230
