Fix a bug that swift clang importer is not setup correctly when prefix
map is used. There are two separate issues:
* CC1 args used to setup clang import when building swift (interface and
sources) are not correctly remapped.
* When loading SDKInfo from SDK path, the SDKSettings.json is not
loading from VFS, thus the file cannot be loaded from remapped path.
rdar://134458611
During the lifecycle of a feature, it may start as an experimental feature and
then graduate to become an upcoming feature. To preserve compatibility with
projects that adopted the feature when it was experimental,
`-enable-experimental-feature` ought to be able to enable upcoming features,
too.
Since projects may use `-enable-experimental-feature` for compatibility with an
older toolchain that does not have the feature as an upcoming feature, there is
no warning when the flag is used to enable an upcoming feature.
Note that if the semantics of a feature change when it graduates from
experimental to upcoming, then the feature must be renamed so that projects
using the experimental feature have an opportunity opt-in to the new semantics
of the upcoming feature.
Resolves rdar://134276783.
When direct cc1 mode is used, the cc1 arguments are generated from extra
clang targets so there is no need to add this extra argument.
Furthermore, the `--target=` is a clang driver argument and is not valid
under cc1 mode.
Needed for: rdar://134090397
This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
The code that generates the runtime path is not right for Windows;
fix it to point at the correct place.
This makes simple use of `swift test.swift` work.
rdar://132598892
In anticipation of adding a new kind of missing import record to `SourceFile`,
clarify the purpose of the existing "missing imports" record with more specific
naming and documentation.
This warning is designed to be an early report of name conflicts in
swiftinterfaces caused by a type having the same name as a module.
Make sure we silence this warning when the workaround
-alias-module-names-in-module-interface is enabled. This is what we
already do for -module-interface-preserve-types-as-written.
rdar://132990400
[Dependency Scanning] Disable validation of Swift dependency modules' existing pre-built candidate binary module files in the scanner, on a non-caching build.
Don't try to figure out the executable names during replay from
libSwiftScan.dylib. The actual executable path for the process actually
doesn't matter in this case to reconstruct the invocation and might
actually be misleading.
Just use `swift-frontend` as a placeheader executable name for
in-process cache replay.
rdar://132758308
As-is, this default interferes with the incremental build machinery which conservatively assumes that binary module dependencies must cause dependents to be re-built.
With `-experimental-lazy-typecheck` specified during module interface emission,
`collectProtocols()` may be the first piece of code to request the extended
type for a given extension and it therefore needs to ignore invalid extensions
and ensure that diagnostics are emitted.
Also, add some `PrettyStackTrace` coverage to `ModuleInterfaceSupport.cpp` to make
investigating future issues easier.
Resolves rdar://126232836.
