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
When synthesizing a declaration and inferring its availability, the synthesized attribute should factor in unavailability of the parent declarations. This recently regressed with https://github.com/apple/swift/pull/63361. However, the previous implementation did not produce correct results, either, because the logic for merging availability attributes produced a non-sensical result when both `unavailable` and `introduced:` availability attributes were merged. For example, this was the result for the synthesized `unownedExecutor` property of an actor when the actor was marked unavailable:
```
@available(macOS, unavailable)
actor A {
// Incorrectly synthesized availability for `unownedExecutor` which results from merging
// the unavailability of the parent and the availability of the UnownedSerialExecutor type.
@available(macOS, unavailable, introduced: macOS 10.15)
@_semantics("defaultActor") nonisolated final var unownedExecutor: UnownedSerialExecutor { get }
}
```
This is fixed by omitting all version components from the synthesized attribute when the overall attribute kind is "unavailable".
Additionally, I discovered that the `concurrency_availability.swift` test case was no longer testing what it intended to test. The conformances to `Actor` for each `actor` in the test were no longer being synthesized and therefore `unownedExecutor` was not being synthesized. That was fixed by importing the `_Concurrency` module directly, which seems to be necessary because of the `-parse-stdlib` flag in the test.
Resolves rdar://106055566
When using access level on imports, consider non-public imports to be
implementation details not exposed to clients. As such, a client loading
a library doesn't need to load non-public transitive dependencies.
This behave like `@_implementationOnly imports` at a module-wide level,
but it is restricted to resilient modules only. An import with any
access-level in a non-resilient module remains visible to transitive
clients.
Add '-validate-clang-modules-once' and '-clang-build-session-file' corresponding to Clang's '-fmodules-validate-once-per-build-session' and '-fbuild-session-file='. Ensure they are propagated to module interface build sub-invocations.
We require these to be first-class Swift options in order to ensure they are propagated to both: ClangImporter and implicit interface build compiler sub-invocations.
Compiler portion of rdar://105982120
Inject the necessary module maps and apinotes via the VFS. This cleans
up the developer build in preparation for a secondary change to remove
this need for deployed scenarios as well. Injecting the content via the
VFS will enable us restore the ability to work with a pristine
installation of Visual Studio, dropping the custom action for the Swift
installer, and open the pathway to per-user installation of Swift.
Thanks to @bnbarham for the help and discussion in resolving the test
issues.
