Conflicts:
lib/Basic/Platform.cpp
```
diff --git a/lib/Basic/Platform.cpp b/lib/Basic/Platform.cpp
index 240edfa144a..1797c87635f 100644
--- a/lib/Basic/Platform.cpp
+++ b/lib/Basic/Platform.cpp
@@ -200,10 +200,7 @@ StringRef swift::getPlatformNameForTriple(const llvm::Triple &triple) {
case llvm::Triple::CUDA:
case llvm::Triple::DragonFly:
case llvm::Triple::DriverKit:
-<<<<<<< HEAD
case llvm::Triple::ELFIAMCU:
-=======
->>>>>>> main
case llvm::Triple::Emscripten:
case llvm::Triple::Fuchsia:
case llvm::Triple::HermitCore:
```
The binary module built from a CAS build will have the embeded bridging
header info with 0 modTime. Allow a regular build to import such a
module with the same behavior as if the module is built from a regular
build.
rdar://126221616
When caching is enabled with include-tree, the bridging header PCH is
created from the include tree directly. Setup the rewriter correctly
when embedding the bridging header into swift binary module.
rdar://125719747
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Clang is using C++17 standard version by default since Clang 16.
Swift’s ClangImporter should do the same, to make sure that clients who run clang and then swiftc without explicit std version see consistent behavior.
rdar://125777068
`-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
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.
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
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.
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
An @_objcImpl extension with no category name *should* implement not only the class’s main @interface, but also any class extension @interfaces. Start making this true by making ObjCInterfaceAndImplementationRequest return all of these decls as the interfaces for such an implementation.
This commit doesn’t actually change Sema or IRGen to process the extra interfaces, so it’s NFC.
