Store `CustomAvailabilityDomain` instances in a folding set on `ASTContext`.
This instances of custom domains to be created without needing to cache them in
disparate locations.
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.
With the acceptance of SE-0458, allow the use of unsafe expressions, the
@safe and @unsafe attributes, and the `unsafe` effect on the for..in loop
in all Swift code.
Introduce the `-strict-memory-safety` flag detailed in the proposal to
enable strict memory safety checking. This enables a new class of
feature, an optional feature (that is *not* upcoming or experimental),
and which can be detected via `hasFeature(StrictMemorySafety)`.
When `ExtensibleEnums` flag is set, it's going to be reflected in
the module file produced by the compiler to make sure that consumers
know that non-`@frozen` enumerations can gain new cases in the
future and switching cannot be exhaustive.
When enable bridging header auto chaining, it is possible for the
compilation to have a PCH file input for the bridging header from a
binary swift module dependency. In this case, we should not report a
bridging header for current module as bridging header can be leaking out
through swiftinterface file.
To fully distinguish the PCH files passed in through different
situation, here are the situations:
* If no chaining is used, only `-import-objc-header` option is used and
it can be used to pass either a header file or a PCH file depending if
GeneratePCH job is requested or not.
* If chaining is enabled, `-import-objc-header` is only used to pass the
header file and `-import-pch` is used to pass PCH file. Chaining mode
requires PCH generation if bridging header is used.
rdar://144623388
This commit makes a number of adjustments to how the diagnostic verifier handles source buffers and source locations. Specifically:
• Files named by `-verify-additional-file` are read as late as possible so that if some other component of the compiler has already loaded the file, even in some exotic way (e.g. ClangImporter’s source buffer mirroring), it will use the same buffer.
• Expectation source locations now ignore virtual files and other trickery; they are based on the source buffer and physical location in the file.
Hopefully this will make `-verify-additional-file` work better on Windows. As an unintended side effect, it also changes how expectations work in tests that use `#sourceLocation()`.
Add ability to automatically chaining the bridging headers discovered from all
dependencies module when doing swift caching build. This will eliminate all
implicit bridging header imports from the build and make the bridging header
importing behavior much more reliable, while keep the compatibility at maximum.
For example, if the current module A depends on module B and C, and both B and
C are binary modules that uses bridging header, when building module A,
dependency scanner will construct a new header that chains three bridging
headers together with the option to build a PCH from it. This will make all
importing errors more obvious while improving the performance.
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.
Extend the module trace format with a field indicating whether a given
module, or any module it depends on, was compiled with strict memory
safety enabled. This separate output from the compiler can be used as
part of an audit to determine what parts of Swift programs are built
with strict memory safety checking enabled.
The symbol graph output from a module can contain an arbitrary number of
files, depending on what extensions it contains, so cache a list of
symbol graph files with their base name and contents so that they can be
replayed.
rdar://140286819
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
This patch adds support for serialization and deserialization of
debug scopes.
Debug scopes are serialized in post order and enablement is
controlled through the experimental-serialize-debug-info flag which
is turned off by default. Functions only referred to by these debug
scopes are deserialized as zombie functions directly.
It might be unexpected to future users that `-swift-compiler-version`
would produce a version aligned to .swiftinterface instead of one used
to build the .swiftmodule file. To avoid this possible confusion, let's
scope down the version to `-interface-compiler-version` flag and
`SWIFT_INTERFACE_COMPILER_VERSION` option in the module.
If swiftinterface doesn't have `-swift-compiler-version` flag
it means that it was generated with an older version of the
Swift compiler. In such cases it would be incorrect to use
"current" compiler version because the field is intended to
indicate the compiler the swiftinterface was built with.
When setting up the ModuleInterfaceChecker, prefer using the module
cache path from command-line invocation `-module-cache-path` before
falling back to clang options.
Usually those two yield the same result, except for LLDB under direct
cc1 argument mode and explicit module build. Under such mode, the cc1
option for module cache path will be stripped since the output PCMs are
explicit passed as output. When LLDB attempted to do an implicit module
compilation for the swift interface, it will not be able to locate the
module cache path from cc1 arguments. On the other hand, the module
cache option has already be inherited by the sub-instance so it can just
directly be located there.
rdar://137610484
to verify ExportedSourceFileRequest == 0.
In release mode only non-zero stats are printed by default now.
Fix diagnostic when compiler is built without statistics support.
Use IncludeTreeFileList instead of full feature CASFS for swift
dependency filesystem. This allows smaller CAS based VFS that is smaller
and faster. This is enabled by the CAS enabled compilation does not
need to iterate file system.
rdar://136787368
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
This commit adds new compiler options -no-warning-as-error/-warning-as-error which allows users to specify behavior for exact warnings and warning groups.
This fixes the debugger's ability to perform expression evaluation when debugging an
executable that was built with both under the following circumstances:
1. explicit module build
2. `-application-extension`
The fix is to include `-fapplication-extension` as an XCC field in the swiftmodule.
This primes the debugger's ClangImporter with the correct flag needed to load the
explicitly built pcm files generated at build time.
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 scanning action does not have any need for handling `-llvm` options, since it will never perform any code-gen. LLVM option processing relies on global option parsing structures, and the scanner has needed to carefully attempt to synchronize access to them. This change guards the configuration of LLVM options to not happen at all for dependency scanning actions, and removes calls to `llvm::cl::ResetAllOptionOccurrences()` that were previously needed.
Resolves rdar://120754696
When MCCAS is used, filter the object file from the CASOutputBackend
because we do not want to write the object file in the CAS, we want
to associate the MCCAS top level CAS Object to the main output of the
CASOutputBackend.
