This patch introduces new diagnostics to the ClangImporter to help
explain why certain C, Objective-C or C++ declarations fail to import
into Swift. This patch includes new diagnostics for the following entities:
- C functions
- C struct fields
- Macros
- Objective-C properties
- Objective-C methods
In particular, notes are attached to indicate when any of the above
entities fail to import as a result of refering an incomplete (only
forward declared) type.
The new diangostics are hidden behind two new flags, -enable-experimental-clang-importer-diagnostics
and -enable-experimental-eager-clang-module-diagnostics. The first flag emits diagnostics lazily,
while the second eagerly imports all declarations visible from loaded Clang modules. The first
flag is intended for day to day swiftc use, the second for module linting or debugging the importer.
We need to modify the pointer pointing to the cancellation flag when reusing an ASTContext for code completion. This is not possible by the previous design because `TypeCheckerOptions` was `const`. Moving the cancellation flag to `ASTContext` will also allow other stages of the compiler to honor a cancellation request.
We've recently added the -experimental-hermetic-seal-at-link compiler flag,
which turns on aggressive dead-stripping optimizations and assumes that library
code can be optimized against client code because all users of the library
code/types are present at link/LTO time. This means that any module that's
built with -experimental-hermetic-seal-at-link requires all clients of this
module to also use -experimental-hermetic-seal-at-link. This PR enforces that
by storing a bit in the serialized module, and checking the bit when importing
modules.
These modules are part of the experimental declarative string processing feature. If accepted to the Standard Library, _StringProcessing will be available via implicit import just like _Concurrency, though _MatchingEngine will still be hidden as an implementation detail.
`_MatchingEngine` will contain the general-purpose pattern matching engine ISA, bytecode, and executor. `_StringProcessing` will contain regular expression and pattern matching APIs whose implementation depends on the matching engine..
Also consolidates frontend flag `-enable-experimental-regex` as `-enable-experimental-string-processing`.
Resolves rdar://85478647.
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.
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.
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
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.
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.
