Seems that VS2019 and other C++ standard libraries include <atomic> as
part of either <string> or <vector>, but not VS2017. When #38782 landed
a new usage of std::atomic started creating compilation problems in the
VS2017 builders (eg. https://ci-external.swift.org/job/oss-swift-windows-x86_64/8736/).
Including the <atomic> header solves the problem.
This commit adds a function to remap the clang arguments passed
during compilation. This is intented to be shared across the
Swift compiler and LLDB to apply path remapping for debug info
paths.
This commit refactors the way ASTs are being built in SourceKit and how `SwiftASTConsumer`s are served by the built ASTs. `SwiftASTManager.h` should give an overview of the new design.
This commit does not change the cancellation paradigm in SourceKit (yet). That is, subsequent requests with the same `OncePerASTToken` still cancel previous requests with the same token. But while previously, we were only able to cancel requests that haven’t started an AST build yet, we can now also cancel the AST build of the to-be-cancelled requests.
With this change in place, we can start looking into explicit cancellation of requests or other cancellation paradigms.
"add inits to toplevel" and "call pattern heuristics" are only used in
code completion. Move them from LangOptions to CodeCompletionContext so
that they don't affect compiler arguments.
Changed the frontend flag to -enable-experimental-lexical-lifetimes from
-enable-experimental-defined-lifetimes.
Changed the attribute on begin_borrow from [defined] to [lexical].
Serialize the canonical name of the SDK used when building a swiftmodule
file and use it to ensure that the swiftmodule file is loaded only with
the same SDK. The SDK name must be passed down from the frontend.
This will report unsupported configurations like:
- Installing roots between incompatible SDKs without deleting the
swiftmodule files.
- Having multiple targets in the same project using different SDKs.
- Loading a swiftmodule created with a newer SDK (and stdlib) with an
older SDK.
All of these lead to hard to investigate deserialization failures and
this change should detect them early, before reaching a deserialization
failure.
rdar://78048939
The Swift driver is passing the optimization record file path via the supplementals output, instead of the flag, on certain circumstances.
Enhance the frontend to check supplemental outputs otherwise the record file will not get emitted when using the new swift driver.
Make sure that we add the appropriate rpaths so that the appropriate
_Concurrency back-deployment library can be picked up.
We don't need to update the Swift driver since it uses the C++ driver
as the source of truth to determine if the relevant rpath should be
added or not.
Remove the option that explicitly enables concurrency back-deployment,
and instead always enable its support in the compiler. Remove the use
of the extraneous CMake option as well.
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
When enabling the build of the back-deployable concurrency library via
the build-script option `--back-deploy-concurrency`, also build the
compiler and (main) concurrency library to support older deployment targets.
Building the compiler for older deployment targets is effectively the
same as implicitly passing
`-Xfrontend -enable-experimental-back-deploy-concurrency`. That option
should probably go away.
Building the primary _Concurrency library for back-deployment means
setting the "SwiftStdlib 5.5" availability back to the earlier
deployment targets. This should have no effect on how the _Concurrency
library binary is built, but it does ensure that the right
availability annotations are in the _Concurrency module.
Add a frontend-only flag `-enable-experimental-back-deploy-concurrency`
to be used to stage in the back deployment of concurrency. At present,
all it does is lower the availability minimums for use of concurrency
features.
We have implemented a libSwiftDriver-based tool to generate prebuilt module cache for
entire SDKs. Anchored on the same infrastructure, we could also generate ABI baselines
for entire SDKs.
