Ideally this would also update the `--version` output to be overridden
by `SWIFT_TOOLCHAIN_VERSION`, but unfortunately various tools rely on
the current format (eg. swift-build).
(cherry picked from commit 3c098782b4)
Improve diagnostics message for swift caching build by trying to emit
the diagnostics early when there is more context to differentiate the
different kind of problems.
After the improvement, CAS Error should be more closer to when there is
functional problem with the CAS, rather than mixing in other kinds of
problem (like scanning dependency failures) when operating with a CAS.
rdar://145676736
(cherry picked from commit 226552bf23)
CoreGraphics can now be rebuilt with C++ interop enabled, which makes this workaround obsolete.
rdar://150211857
(cherry picked from commit 571bd8e9d9)
Currently, the macro plugin options are included as cache key and the
absolute path of the plugin executable and library will affect cache
hit, even the plugin itself is identical.
Using the new option `-resolved-plugin-validation` flag, the macro
plugin paths are remapped just like the other paths during dependency
scanning. `swift-frontend` will unmap to its original path during the
compilation, make sure the content hasn't changed, and load the plugin.
It also hands few other corner cases for macro plugins:
* Make sure the plugin options in the swift module is prefix mapped.
* Make sure the remarks of the macro loading is not cached, as the
mesasge includes the absolute path of the plugin, and is not
cacheable.
rdar://148465899
(cherry picked from commit 3d38d0dd56)
We're not ready to start emitting warnings when type-checking modules from
interface. It is causing performance regressions and spurious diagnostics to be
emitted.
Reverts a small part of https://github.com/swiftlang/swift/pull/80360.
Resolves rdar://148257136.
An objcImpl bug previously caused `@_hasStorage` to be emitted inside some extensions in module interfaces. An earlier commit in this PR created an error for this, but for backwards compatibility, it would actually be better to simply ignore the attribute in module interfaces. Modify TypeCheckStorage to emit a warning, not an error, in this situation.
Additionally, modify the module interface loader to show warnings when you verify a module interface, but not for other module interface uses (like compiling or importing one). The assumption here is that if you’re verifying a module interface, you’re either the author of the module that created it or you’re investigating a problem with it, and in either case you’d like to be told about minor defects in case they’re related.
Fixes rdar://144811653 thoroughly.
With '-sdk-module-cache-path', Swift textual interfaces found in the SDK will be built into a separate SDK-specific module cache.
Clang modules are not yet affected by this change, pending addition of the required API.
This removes a workaround from the module interface loader, which was forcing Darwin to be rebuilt from their textual interfaces with C++ interop disabled, even if the current compilation explicitly enables it.
See also 3791ccb6.
rdar://142961112
https://github.com/swiftlang/swift/pull/37774 added '-clang-target' which allows us to specify a target triple that only differs from '-target' by the OS version, when we want to provide a different OS version for API availability and type-checking, in order to set a common/unified target triple for the entire Clang module dependency graph, for presenting a unified API surface to the Swift client, serving as a maximum type-checking epoch.
This change adds an equivalent flag for the '-target-variant' configuration, as a mechanism to ensure that the entire module dependency graph presents a consistent os version.
For build systems that already generate these files, it makes sense to include the aliases so that the map file serves as a comprehensive index of how the module inputs are referenced.
This removes a workaround from the module interface loader, which was forcing AppKit and UIKit to be rebuilt from their textual interfaces with C++ interop disabled, even if the current compilation explicitly enables it.
The workaround was previously put in place because of a compiler error:
```
error: type 'AttributeScopes.AppKitAttributes.StrikethroughStyleAttribute' does not conform to protocol 'AttributedStringKey'
note: possibly intended match 'AttributeScopes.AppKitAttributes.StrikethroughStyleAttribute.Value' (aka 'NSUnderlineStyle') does not conform to 'Hashable'
```
`NSUnderlineStyle` is a C/C++ type from AppKit that is declared using `NS_OPTIONS` macro. `NS_OPTIONS`/`CF_OPTIONS` macros have different expansions in C vs C++ language modes. The C++ expansions weren't handled correctly by ClangImporter, resulting in two distinct Swift types being created: a `typealias NSUnderlineStyle` which was marked as unavailable in Swift, and `enum NSUnderlineStyle`. This mostly worked fine, since the lookup logic was picking the enum during regular name lookup. However, this silently broke down when rebuilding the explicit conformance from `AppKit.swiftinterface`:
```
extension AppKit.NSUnderlineStyle : Swift.Hashable {}
```
Swift was picking the (unavailable) typealias when rebuilding this extension, which means the (available) enum wasn't getting the conformance.
This is verified by an existing test (`test/Interop/Cxx/objc-correctness/appkit-uikit.swift`).
rdar://142961112
Most SDKs use only swiftinterfaces under usr/lib/swift. Let's make sure
we standardize this behavior and use only swiftinterface when they are
present, even if there are also binary swiftmodule files available.
Apply the same logic to SubFrameworks as well while we're at it.
rdar://145316821
This failure will most-likely result in the dependency query failure which will fail the scan. It will be helpful if the scanner emitted diagnostic for each such module it rejected to explain the reason why.
Resolves rdar://142906530
The AppKit/UIKit overlay refers to symbols declared via NS_OPTIONS
macro, which is causing issues in C++ language mode due to the macro
definition being different. This teaches the module interface loader to
drop the C++ interop flag when rebuilding the AppKit and UIKit overlay
from its interface.
This is the same fix as #78636, but for different modules.
rdar://143033209
Diagnostics may be emitted while parsing command line arguments. This implies
that the options which affect how diagnostics are emitted and presented need to
be parsed first.
Diagnostics are suppressed when parsing swiftinterface files, since the
warnings emitted from compiling the swiftinterface of a dependency would just
be a nuisance. It follows that warnings generated when parsing the arguments in
a swiftinterface file should also be suppressed, but that wasn't happening
because the diagnostic engine of the main compile was used for parsing. Pass
the diagnostic engine of the compiler subinstance instead, and proactively
suppress warnings before parsing begins.
Resolves rdar://142814164.
The CoreGraphics overlay refers to symbols declared via `CF_OPTIONS` macro, which is causing issues in C++ language mode due to the macro definition being different.
This teaches the module interface loader to drop the C++ interop flag when rebuilding the CoreGraphics overlay from its interface.
rdar://142762174
This effects local swift development only and is needed now to use -enable-ossa-modules in local tests that
import Synchronization and Distributed which are non-ossa.
In https://github.com/swiftlang/swift/pull/77156, normalization was introduced
for -target-variant triples. That PR also caused -target-variant arguments to
be inherited from the main compilation options whenever building dependency
modules from their interfaces, which is incorrect. The -target-variant option
must only be specified when compiling a "zippered" module, but the dependencies
of zippered modules are not necessarily zippered themselves and
indiscriminantly propagating the option can cause miscompilation.
The new, more targeted approach to normalizing arm64e triples simply uses the
arch and subarch of the -target argument of the main compile to decide whether
the subarch of both the -target and -target-variant arguments of a dependency
need adjustment.
Resolves rdar://135322077 and rdar://141640919.
This teaches Swift to rebuild the CxxStdlib overlay module from its interface when using a C++ standard library that is not the platform default, specifically libc++ on Linux.
rdar://138838506
This makes sure that the compiler does not emit `-enable-experimental-cxx-interop`/`-cxx-interoperability-mode` flags in `.swiftinterface` files. Those flags were breaking explicit module builds. The module can still be rebuilt from its textual interface if C++ interop was enabled in the current compilation.
rdar://140203932
Teach dependency scanner to construct build commands using resolved
plugin search path option. This ensures the modules that do not have
access to the macro plugins will not have a different variant due to
different plugin search path.
rdar://136682810
Add flag `-load-resolved-plugin` to load macro plugin, which provides a
pre-resolved entry into PluginLoader so the plugins can be loaded based
on module name without searching the file system. The option is mainly
intended to be used by explicitly module build and the flag is supplied
by dependency scanner.
Based on preliminary work from @rmaz.
The compilation arguments for a swiftinterface file are preprocessed to
modify the `-target` argument to match the preferred target (which comes
from the command line) in cases in which the sub-architecture differs,
but it is compatible (for example using `arm64e` when `arm64` is being
compiled), but this was not done for the target variant, which ended up
with mismatches on the sub-architecture used by the target and target
variant, which fails an assert in assert toolchains.
Otherwise they get built with an empty SDK name string and we do not get the benefit of the SDK name compatibility check in case they are loading modules from an incompatible SDK
Resolves rdar://135972810
Make sure ClangExtraArgs are inherited in the subinstance for module
lookup/building when direct cc1 mode is used. This is useful for lldb,
which does a slight different variant of the explicit module build
that do not have swift-driver cooridination and replies on the
subInstance to load swiftmodule. When such configuration is used, if
DirectCC1 compile option is inherited without any extra cc1 arguments,
the clang importer inside the sub-instance is actually malformed,
causing the swift instance failed to be created.
rdar://135611011
Use a stricter module hash for modules as moving towards more explicit
modules. Previously, a normalized target triple without deployment
target is used as part of the module hash, with the assumption that
deployment target should not change binary module generated.
In reality, the binary module compilation also needs to provide the
typecheck for all interface to ensure the underlying C/ObjC module that
built with the correct deployment target does provide the interfaces to
pass typecheck. Using a stricter module hash can avoid the potentially
confusing error when importing the module.
This commit adds following to module hash to distinguish swiftmodules.
* Deployment target
* -application-extension
rdar://134301179
