and make `@_unsafeInheritExecutor` a suppressible feature.
Some language features are required in order to parse a
declaration correctly, but some can safely be ignored.
For the latter, we'd like the module interface to simply
contain the declaration twice, once with the feature and
once without. Some basic support for that was already
added for the SpecializeAttributeWithAvailability feature,
but it didn't interact correctly with required features
that might be checked in the same `#if` clause (it simply
introduced an `#else`), and it wasn't really set up to
allow multiple features to be handled this way. There
were also a few other places that weren't updated to
handle this, presumably because they never coincided
with a `@_specialize` attribute.
Introduce the concept of a suppressible feature, which
is anything that the ASTPrinter can modify the current
PrintOptions in order to suppress. Restructure the
printing of compatibility checks so that we can print
the body multiple times with different settings.
Print required feature checks in an outer `#if...#endif`,
then perform a separate `#if...#else...#endif` within
if we have suppressible features. If there are multiple
suppressible features, check for the most recent first,
on the assumption that it will imply the rest; then
perform subsequent checks with an `#elsif` clause.
This should be a far more solid foundation on which to
build compatibility checks in the future.
`@_unsafeInheritExecutor` needs to be suppressible
because it's been added to some rather important
existing APIs. Simply suppressing the entire decl will
effectively block old tools from using a new SDK to
build many existing projects (if they've adopted
`async`). Dropping the attribute changes the semantics
of these functions, but only if the compiler features
the SE-0338 scheduling change; this is a very narrow
window of main-branch development builds of the tools,
none of which were officially released.
- Rename StepLimit to MaxRuleCount, DepthLimit to MaxRuleLength
- Rename command line flags to -requirement-machine-max-rule-{count,length}=
- Check limits outside of PropertyMap::buildPropertyMap()
- Simplify the logic in RequirementMachine::computeCompletion()
A scoped-down version of #39307. Implement extension of bound generic types. The important bit here is in TypeCheckGeneric where we now use the underlying type of a typealias and its associated nominal type decl when we're generating substitutions for the extended type.
Put this behind a new experimental flag
-enable-experimental-bound-generic-extensions
Resolves SR-4875
Resolves rdar://17434633
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 PR adds a new flag -file-compilation-dir, which does the same thing as -ffile-compilation-dir in Clang.
swiftc -g -ffile-compilation-dir=. path/to/foo.swift gives us identical debug info paths regardless of what location we compiled the file from. It's useful to debug correctly using object files built on different machines in different locations.
There's also a long-existed TODO comment.
Resolves SR-5694
While implicitly building .swiftinterface, the interface may import other binary modules.
These binary modules may contain serialized search paths that have been obfuscated. To help
interface building commands recover these search paths, we need to pass down the obfuscators
to the module building commands.
rdar://87840268
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`.
Add new `-print-ast-decl` frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.
The existing `-print-ast` option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.
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.
PublicCMOSymbols stores symbols which are made public by cross-module-optimizations.
Those symbols are primarily stored in SILModule and eventually used by TBD generation and validation.
Replaced the -disable-copy-propagation flag with
-enable-copy-propagation=false where the latter is a new multi-var
-enable-copy-propagation= which can take one of three values:
- true
- requested-passes-only
- false
Previously, the default value for SILOptions::LexicalLifetimes was based
on a copy propagation behavior (which can then be overridden by the
flags for lexical lifetimems) only when the copy propagation was
explicitly specified. Instead, set base the default value for this
option (SILOptions::LexicalLifetimes) on the effective copy propagation
behavior (i.e. SILOptions::CopyPropagation) regardless of whether an
explicit behavior has been specified.
Doing so will ensure that the desired behavior occurs as the default
behavior for copy-propagation changes, but for now this change is NFC.
