It doesn't really make sense for a conditional conformance requirement
for `Copyable` to depend on any other requirement other than other
`Copyable` conformance requirements.
resolves rdar://124967739
When printing declarations with `NoncopyableGenerics2` suppressed we must avoid
printing the `@_preInverseGenerics` attribute and any `borrowing` or
`consuming` parameter ownership modifiers.
Pitch - https://github.com/apple/swift-evolution/pull/2305
Changes highlights:
dependsOn(paramName) and dependsOn(scoped argName) syntax
dependsOn(paramName) -> copy lifetime dependence for all parameters/self except
when we have Escapable parameters/self, we assign scope
lifetime dependence.
Allow lifetime dependence on parameters without ownership modifier.
Always infer copy lifetime dependence except when we have
Escapable parameters/self, we infer scope lifetime dependence.
Allow lifetime dependence inference on parameters without ownership modifier.
Due to the mapping of iOS platform availability to tvOS platform availability,
we were ending up inferring an availability attribute `@available(tvOS)` for
an associated type, which does not parse properly. Suppress the creation
of inferred availability attributes when they convey no information
(e.g., because they have no introduced/deprecated/obsoleted/etc. in them).
Fixes rdar://123545422.
Nested types with inverse requirements on generic parameters would
sometimes print incorrectly. We only print the inverses on outer generic
parameters for extensions.
fixes rdar://123281976
We want extensions to introduce default Copyable/Escapable just like
other generic contexts, so that once Optional adopts ~Copyable,
an `extension Optional` actually adds `Wrapped: Copyable` by default.
In cases where the generic parameter is class-constrained,
`GenericSignature::requiresProtocol` will not contain `Copyable` or
`Escapable` because GenericSignature minimization will recognize that
the class already requires them.
Thus, because classes always require those protocols, we can
simply ask if the generic parameter is required to be a class to
determine if it had any inverses.
Swift generates implicit constructors for inherited designated initializers in
case some implicit initialization (such as running property initializer
expressions) needs to run after calling the initializer on the superclass.
These implicit initializers are printed in .swiftinterfaces and previously they
could cause the interface to fail to typecheck when one of the parameters is
declared to be unavailable-in-Swift. These initializers need to be generated
because they may be called from Objective-C where the unavailable-in-Swift
designation is irrelevant. To account for this possibility, relax availability
checking to allow this narrow exception only in .swiftinterfaces.
Another possible but more complicated solution would be to print the
initializers with an attribute that indicates that the initializer is inherited
and implicit. This would allow the typechecking exception to be more precise
but seems unnecessarily complicated given that the exception is only needed in
.swiftinterfaces, which are already compiler generated.
Resolves rdar://77221357
We can't simply emit the desugared, expanded version of the requirements
because there's no way to pretty-print the type `some ~Copyable` when
the `~Copyable`'s get replaced with the absence of `Copyable`. We'd be
left with just `some _` or need to invent a new top type so we can write
`some Top`. Thus, it's best to simply reverse the expansion of default
requirements when emitting a swiftinterface file.
Fixes three tests failing on Windows:
```
Swift(windows-x86_64) :: ModuleInterface/ModuleCache/force-module-loading-mode-archs.swift
Swift(windows-x86_64) :: ModuleInterface/ModuleCache/force-module-loading-mode-framework.swift
Swift(windows-x86_64) :: ModuleInterface/ModuleCache/force-module-loading-mode.swift
```
These test cases remove read access to the `.swiftmodule` . The expected
behavior is that the compiler checks `fs.exists("path-to.swiftmodule")`
, determines that the file exists and chooses to use it instead of the
`.swiftinterface`. Compilation then fails because the file cannot be
read.
e22cf2e993/lib/Frontend/ModuleInterfaceLoader.cpp (L752)
On Windows, we were denying `R` access, which is broader than only read
access to file contents but also includes file attributes and
permissions. This caused `fs.exists` to fail since it relies on
`fs.status`, which could not open the file with `CreateFileW`. The fix
is is to only deny `RD - read data/list directory` access.
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).
This flag restricts availability of certain symbols to ensure the code cannot use declarations that are explicitly unavalable to extensions. This restriction should be passed down to dependency modules also.
Raw values of enum cases from another module are not specified in the declaration of the enum unless that enum is `@objc`. This meant that `EnumRawValuesRequest` was computing potentially incorrect raw values when the enum declaration supported it and was emitting incorrect diagnostics for other enum decls.
Resolves SR-14355 and rdar://75451691
mangleOpaqueTypeDecl() used to enable DWARFMangling, which
ignores @_originallyDefinedIn, which would in turn break module
interfaces.
Fixes rdar://problem/86480663.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
If we are building for ARM64 but we try to import a module with only an ARM64e interface, fall back to importing said interface.
This is the reverse of a similar fallback briefly introduced last year, but removed in #31196.
DummyFramework.framework has two different properties to support two different kinds of test cases: to support ModuleInterface/build-alternative-interface-framework.swift, its macOS interfaces are broken, but to support ModuleInterface/arm64e-fallback.swift, it supports only arm64, not arm64e, on iOS. The arm64e test's behavior is about to change, which will complicate all of this. As a preliminary step, make the two tests use two different frameworks so they aren't so intertwined.
This temporarily keeps the arm64e test using the name "DummyFramework", but that will change.
Although users should usually use a prebuilt standard library, in those rare configurations where one needs to be built, the compiler appears to hang for several minutes, even on a trivial compilation. This commit adds a remark that's emitted when this happens, explaining that the standard library is being rebuilt and it will take a few minutes.
