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.
This mechanism allows the compiler to use a backup interface file to build into a binary module when
a corresponding interface file from the SDK is failing for whatever reasons. This mechansim should be entirely opaque
to end users except several diagnostic messages communicating backup interfaces are used.
Part of rdar://77676064
- Introduce an UnownedSerialExecutor type into the concurrency library.
- Create a SerialExecutor protocol which allows an executor type to
change how it executes jobs.
- Add an unownedExecutor requirement to the Actor protocol.
- Change the ABI for ExecutorRef so that it stores a SerialExecutor
witness table pointer in the implementation field. This effectively
makes ExecutorRef an `unowned(unsafe) SerialExecutor`, except that
default actors are represented without a witness table pointer (just
a bit-pattern).
- Synthesize the unownedExecutor method for default actors (i.e. actors
that don't provide an unownedExecutor property).
- Make synthesized unownedExecutor properties `final`, and give them
a semantics attribute specifying that they're for default actors.
- Split `Builtin.buildSerialExecutorRef` into a few more precise
builtins. We're not using the main-actor one yet, though.
Pitch thread:
https://forums.swift.org/t/support-custom-executors-in-swift-concurrency/44425
Previously, when the standard library module interface was broken, Swift would try to rebuild it repeatedly during -compile-module-from-interface jobs because `ASTContext::getStdlibModule()` would try to load the standard library again each time it was called. This led to extremely slow compilations that repeatedly emitted the same errors.
To avoid this, we make ModuleInterfaceBuilder try to load the standard library right away and bail out if it can’t.
Fixes rdar://75669548.
There is a known issue with module interfaces where a type with the same name as a module will disrupt references to types in that module. Fully fixing it will require a new language feature (SR-898) which is not yet available. In the meantime, module interfaces support a workaround flag (“-Xfrontend -module-interface-preserve-types-as-written”) which prints an alternate form that usually works. However, you have to know to add this flag, and it’s not obvious because nothing breaks until a compiler tries to consume the affected module interface (or sometimes even one of its clients).
This commit emits a warning during module interface emission whenever the module interface either imports a type with the same name as the module being built, or declares a type with the same name as a visible module. This lets the user know that the type may cause problems and they might need to implement a workaround.
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
`InterfaceSubContextDelegateImpl` causes sub-instances to inherit `-fmodule-map-file=` options.
Those Module Maps become file dependencies of all downstream PCMs and their depending Swift modules, even though they really aren't.
This causes frequent re-builds of the Module Cache contents when seemingly-unrelated files are touched.
Explicit Module Builds rely on these options for building Swift Interface files, so for now we just disable inheritance of these options in Implicit Module builds.
Maintain the ability for older Swift compilers to read .swiftinterfaces
that make use of result builders by always emitting @_functionBuilder
rather than the newer @resultBuilder.
Make `make-unreadable` python 3 compatible. `POINTER` is now in
`ctypes` rather than in `ctypes.wintypes`. Use the new location which
is compatible across python 2 and python 3.
For cases like this:
```swift
struct X {}
struct Y {}
func overloaded<T>(_ value: T) -> T { value }
func overloaded<T>(_ value: T) -> Int { 0 }
func test(x: inout X, y: Y) {
x = overloaded(y)
}
```
Solver would record a `IgnoreAssignmentDestinationType` fix per overload,
`diagnoseForAmbiguity` could be used to properly diagnose ambiguity cases
like that.
Introduce a fix/diagnostic when there is a contextual mismatch
between source and destination types of the assignment e.g.:
```swift
var x: Int = 0
x = 4.0 // destination expects an `Int`, but source is a `Double`
```
