`-mcpu` is a deprecated "alias" (unsupported) on x86 targets for
`-mtune`. Unlike `-mcpu`, `-mtune` simply tunes the code for the CPU but
does not prevent execution on other targets. In order to match the
behaviour of `-mcpu` on ARM, we must use both `-march=` and `-mtune=`.
Adjust this behaviour to allow tuning of code for non-Darwin targets.
New code introduced for objcImp class extension support failed to check whether a class extension would be visible to Swift before importing it. This caused Swift to import extensions declared in private headers that ought not to be visible. Add the needed visibility check to the loop.
Fixes rdar://123543707.
In `getNormalInvocationArguments`, use a triple that corresponds to `ClangTarget`. This
matches the behavior of `addCommonInvocationArguments`.
rdar://124539816
Support `-vfsoverlay` swift option for explicit module build (including
caching build). Previously, if the interface file is discovered from a
location that is remapped by overlay, module cannot be built correctly.
Make sure the overlay options are passed down to all interface
compilaiton command.
For caching build, need to make sure the overlay itself is part of the CAS
file system so the downstream compilation can discover that.
rdar://123655183
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
The `bridging` header for C++ interop was calculating an include
directory using `CMAKE_BINARY_DIR` and `CMAKE_CFG_INTDIR` while the rest
of the headers consistently use `CMAKE_CURRENT_BINARY_DIR` and no
`CMAKE_CFG_INTDIR`.
In some configurations of CMake (for example when using Swift as an
external project of LLVM and building an unified toolchain), this means
that the `brigding` header will end up in a different directory than the
rest of the headers, which complicates testing.
The changes in this commit reuses `SWIFT_INCLUDE_DIR` to keep
consistency with the rest of the headers. Any build started by
`build-script` should not notice the difference.
The recent Clang compiler change makes `-fno-modulemap-allow-subdirectory-search` the default behavior. This means that projects that use C++ interop and `#include <swift/bridging>` no longer compile, since Clang won't search for the SwiftBridging module under `usr/include/swift` anymore.
This change adds a new modulemap file to be installed at `toolchain/usr/include/module.modulemap`. This modulemap is under a default Clang include search path, which will make sure Clang can discover the SwiftBridging module.
rdar://123334601
Model indexing output as an optional output from the swift compiler
as the build system has no knowledge about them and they can be
regenerated by indexer. Make sure the indexing store output is produced
when cache hit so the compilation is done for the module. If cache hit,
no indexing data is produced since no compilation is done.
rdar://123331335
When caching build is enabled, teach dependency scanner to report
command-lines with `-direct-clang-cc1-module-build` so the later
compilation can instantiate clang importer with cc1 args directly. This
avoids running clang driver code, which might involve file system
lookups, which are the file deps that are not captured and might result
in different compilation mode.
rdar://119275464
Otherwise they may have module dependencies of their own which will not be detected by the scanner and included in the list of explicit inputs for compilation.
If an imported type's conformance cannot be implicitly inferred, allow
it to be explicitly stated via
`__attribute__((__swift_attr__("_BitwiseCopyable")))`.
This adds a new implementation of virtual method dispatch that handles reference types correctly.
Previously, for all C++ types an invocation of a virtual method would actually get dispatched statically. For value types this is expected and matches what C++ does because of slicing. For reference types, however, this is incorrect, we should do dynamic dispatch.
rdar://123852577
ClangImporter’s SwiftLookupTables map Swift names to their corresponding Clang declarations. These tables are built into a module’s clang .pcm file and missing or inaccurate entries can cause name lookup to fail to find an imported declaration.
Swift has always included a helper function that would dump these tables, and swift-ide-test has a command-line switch that would invoke it, but these tools are clumsy to use in many debugging scenarios. Add a frontend flag that dumps the tables at the end of the frontend job, making it a lot easier to get at this information in the context of a specific compilation.
When prefix mapping paths that are used in clang, ensure we are
consistently using the same prefix mapper from clang. This prevents
mismatches that could cause modules to fail to load.
rdar://123324072
This fixes a compiler error that occurred while building `CxxStdlib.swiftmodule` and other projects that use C++ interop: `error: cannot find type 'std' in scope`.
The compiler was creating two distinct `swift::ModuleDecl` instances for the CxxStdlib module while building the CxxStdlib overlay: one as a main module (the module that is currently being compiled), one as a dependency of the main module. This confused the Swift name lookup logic down the road.
This only happened with recent libc++.
See the inline comment for more details.
rdar://122815523
Fix the bridging header dependencies calculation for explicit module
build, especially for caching which needs an accurate list of deps for
compute cache key correctly.
Previously, the bridging header deps are computed from `ModuleGraph`
from the clang dependency scanner, which can be affected by already seen
modules. It causes the dependencies to be missing for bridging header if
the module is seen by main swift source module.
Now report only the directly module dependencies from bridging header,
then compute all the transitive dependencies before calculating all the
cache keys.
rdar://123156636
