Replace the existing `-enable-experimental-clang-importer-diagnostics`
flag with an opt-out version entitled `-disable-experimentalc-clang-importer-diagnostics`.
Enable the beviour previously hidden behind the old flag by default.
This feature allows the following construct to work:
protocol P1 {
associatedtype T : P1
}
protocol P2 {
associatedtype T : P2
}
func foo<T : P1 & P2>(_: T) {}
However, I haven't figured out how to make it work with rewrite system
minimization, so it's already disabled when you use the requirement
machine for protocol or generic signature minimization. In addition to
that it adds some complexity.
I haven't found any real-world uses of this pattern yet, so I'm going
to try to turn it off, and if nobody complains, remove the support
altogether.
If people do complain, we'll have to figure out how to make it work with
minimization.
Allow a user-defined `buildBlock(combining:into:)` to combine subexpressions in a block pairwise top to bottom. To use `buildBlock(_combining:into:)`, the user also needs to provide a unary `buildBlock(_:)` as a base case. The feature is being gated under frontend flag `-enable-experimental-pairwise-build-block`.
This will enable use cases in `RegexBuilder` in experimental declarative string processing, where we need to concatenate tuples and conditionally skip captureless regexes. For example:
```swift
let regex = Regex {
"a" // Regex<Substring>
OneOrMore("b").capture() // Regex<(Substring, Substring)>
"c" // Regex<Substring>
Optionally("d".capture()) // Regex<(Substring, Substring?)>
} // Regex<Tuple3<Substring, Substring, Substring?>>
let result = "abc".firstMatch(of: regex)
// MatchResult<(Substring, Substring, Substring?)>
```
In this example, patterns `"a"` and `"c"` have no captures, so we need to skip them. However with the existing result builder `buildBlock()` feature that builds a block wholesale from all subexpressions, we had to generate `2^arity` overloads accounting for any occurrences of captureless regexes. There are also other complexities such as having to drop-first from the tuple to obtain the capture type. Though these features could in theory be supported via variadic generics, we feel that allowing result builders to pairwise combine subexpressions in a block is a much simpler and potentially more useful approach.
With `buildBlock(_combining:into:)`, the regex builders can be defined as the following, assuming we have variadic generics:
```swift
enum RegexBuilder {
static func buildBlock() -> Regex<Substring>
static func buildBlock<Match>(_ x: Regex<Match>) -> Regex<Match>
static func buildBlock<
ExistingWholeMatch, NewWholeMatch, ExistingCaptures..., NewCaptures...
>(
_combining next: Regex<(NewWholeMatch, NewCaptures...)>,
into combined: Regex<(ExistingWholeMatch, ExistingCaptures...)>
) -> Regex<Substring, ExistingCaptures..., NewCaptures...>
}
```
Before we have variadic generics, we can define overloads of `buildBlock(_combining:into:)` for up to a certain arity. These overloads will be much fewer than `2^arity`.
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.
