The key thing is that the move checker will not consider the explicit copy value
to be a copy_value that can be rewritten, ensuring that any uses of the result
of the explicit copy_value (consuming or other wise) are not checked.
Similar to the _move operator I recently introduced, this is a transparent
function so we can perform one level of specialization and thus at least be
generic over all concrete types.
These include _move and @_noImplicitCopy. I still need to wire up the parsing of
those behind this feature.
The reason that I am adding this now is that I am going to now need to make some
changes behind a feature flag and I have not yet needed to add one. The specific
reason I needed to add one here is to ensure that I properly guard inside _move
the call to Builtin.move so as to prevent a "cond_fail" incident.
P.S.: This work depends on experimental lexical lifetimes being enabled as well,
so I did that at the same time in this PR.
Previously, the flag was a LangOptioins. That didn't make much sense because
this isn't really a user-facing behavior. More importantly, as a member
of that type type it couldn't be accessed when setting up pass
pipelines. Here, the flag is moved to SILOptions.
This additional supplement output should capture semantic info the compiler has
captured while building a Swift module. Similar to the source info file, the content of
the semantic info file should only be consumed by local tooling written in Swift.
Intro the frontend flag `-check-api-availability-only` that limits
availability checking to the API and SPI. This mode doesn't check the
availability of non-inlinable function bodies and of non-ABI-public decl
signatures.
This mode goal is to check all that is printed in the swiftinterface
file. It should be used in place of the wider
`-disable-availability-checking` when generating an interface for
platforms with no binaries.
rdar://81679692
Introduce a compiler flag that warnings about any public types defined in
a module that are neither explicitly `Sendable` nor explicitly
non-`Sendable` (the latter of which has no spelling currently), which
is intended to help with auditing a module for Sendable conformances.
This commit adds a new frontend flag that applies debug path prefixing to the
paths serialized in swiftmodule files. This makes it possible to use swiftmodule
files that have been built on different machines by applying the inverse map
when debugging, in a similar fashion to source path prefixing.
The inverse mapping in LLDB will be handled in a follow up PR.
Second pass at #39138
Tests updated to handle windows path separators.
This reverts commit f5aa95b381.
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.
