Follow the feature flag convention for capitalization and be
consistent with the related NoncopyableGenerics feature.
This is a new feature that no wild Swift code has used it yet:
commit e99ce1cc5d
Author: Kavon Farvardin <kfarvardin@apple.com>
Date: Tue Dec 5 23:25:09 2023
[NCGenerics] add `~Escapable`
Basic implementation of `~Escapable` in the type system.
Previously, 'IntroducerLoc' and 'ThePattern' were only used for pattern
binidng cases. Create a new 'ConditionalPatternBindingInfo' type to
cover such cases, and make 'StmtConditionElement' a pure 'PointerUnion'
type.
This makes it clear which fields are used in which condition kind. Also,
we can expect overall size reduction of StmtCondition when the
majority of the conditions are simple boolean expressions.
Correctly determining the DeclContext needed for an
ExplicitCaughtTypeRequest is tricky for a number of callers, and
mistakes here can easily lead to redundant computation of the caught
type, redundant diagnostics, etc.
Instead, put a `DeclContext` into `DoCatchStmt`, because that's the
only catch node that needs a `DeclContext` but does not have one.
The spelling kind was only ever set to
`StaticSpellingKind::None`, and the static location
was never used for anything (and should be queried
on the storage anyway). This doesn't affect the
computation of `isStatic` since `IsStaticRequest`
already takes the static-ness from the storage for
accessors.
Now that the macro expansion machinery is wrapping the contents of a
body macro in curly braces, parse it as a single brace statement. This
has the advantage of giving us real locations for `{` and `}` rather
than synthesizing them, and simplifies the implementation of macro
body expansion somewhat.
The implementation is not 100% perfect but I don’t think it’s worth putting too much effort into it passing more information down in the parser if 'repeat' and 'each' are valid if we are going to remove the current parser anyway.
rdar://95725895
During the review of SE-0413, typed throws, the notion of a `do throws`
syntax for `do..catch` blocks came up. Implement that syntax and
semantics, as a way to explicitly specify the type of error that is
thrown from the `do` body in `do..catch` statement.
We accepted unnamed closure parameters if the type was an array literal, dictionary literal, tuple or function (because the `[` or `(` starting the type was sufficient to disambiguate the type from the parameter’s name). This was never an accepted syntax and we should disallow it.
Function body macros allow one to introduce a function body for a
particular function, either providing a body for a function that
doesn't have one, or wholesale replacing the body of a function that
was written with a new one.
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.
Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
The field `IsForASTGen` only exists when `SWIFT_BUILD_SWIFT_SYNTAX` is
defined, but the usage was unprotected. The whole function can be inside
the protected block because it only seems to be invoked from inside
blocks already protected by `SWIFT_BUILD_SWIFT_SYNTAX`.
Fix for #69761
There are sometimes parsing stuations where we don't want to
emit a parsing error, because of feature guarding. For
example, if a Feature involves new syntax for a type, we
must be able to parse both the true and false sides of an
ifdef guarding that new syntax based on a Feature flag.
* 'ASTGenVisitor' has a reference to a legacy C++ Parser configured for
ASTGen.
* If 'ASTGenVisitor' encounters a AST node that hasn't been migrated,
call parse(Decl|Stmt|Expr|Type) to parse the position using the legacy
parser.
* The legacy parser calls ASTGen's
'swift_ASTGen_build(Decl|Stmt|Expr|Type)' for each ASTNode "parsing"
(unless the call is not directly from the ASTGen.)
rdar://117151886
'ParseDeclOptions' can be trivially calculated solely from the current
decl context. To reduce the number of the contextual parameters,
calculate it inside the function.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
Introduce a macro that can stamp out wrapper
classes for underlying C++ pointers, and use
it to define BridgedDiagnosticEngine in
ASTBridging. Then, migrate users of
BridgedDiagEngine onto it.
Improve the diagnostics for situations where multiple access-level modifiers are used on the same declaration. Keep the original duplicate error message if the access levels are the same.
