Use similar scheme as DeclAttribute.
* Create `BridgedTypeAttribute.createSimple()` and
`BridgedTypeAttributes.add()`, instead of
`BridgedTypeAttributes.addSimple()`
* Create `DeclAttributes::createSimple()` to align with `TypeAttribute`
This should allow us to eventually simplify parsing of simple string literals in the new parse by not having to handle indentation of multiline string literals.
Remove this bit from function decls and closures.
Instead, for closures, infer it from the presence
of a single return or single expression AST node
in the body, which ought to be equivalent, and
automatically takes result builders into
consideration. We can also completely drop this
query from AbstractFunctionDecl, replacing it
instead with a bit on ReturnStmt.
Rather than doing the transform in the parser, and
then potentially undoing it in Sema, move the
entire transform into Sema. This also lets us
unify the logic between function decls and
closures, and allows ASTGen to benefit from it.
The old TypeAttributes reprsentation wasn't too bad for a small number of
simple attributes. Unfortunately, the number of attributes has grown over
the years by quite a bit, which makes TypeAttributes fairly bulky even at
just a single SourceLoc per attribute. The bigger problem is that we want
to carry more information than that on some of these attributes, which is
all super ad hoc and awkward. And given that we want to do some things
for each attribute we see, like diagnosing unapplied attributes, the linear
data structure does require a fair amount of extra work.
I switched around the checking logic quite a bit in order to try to fit in
with the new representation better. The most significant change here is the
change to how we handle implicit noescape, where now we're passing the
escaping attribute's presence down in the context instead of resetting the
context anytime we see any attributes at all. This should be cleaner overall.
The source range changes around some of the @escaping checking is really a
sort of bugfix --- the existing code was really jumping from the @ sign
all the way past the autoclosure keyword in a way that I'm not sure always
works and is definitely a little unintentional-feeling.
I tried to make the parser logic more consistent around recognizing these
parameter specifiers; it seems better now, at least.
_resultDependsOn and transferring are - at least currently - only used
as type specifiers, not decl modifiers. And if they are actually
specified as a decl modifiers, they're just accepted and ignored, which
is not ideal.
This removes the distinction between argument completions and postfix expr paren completions, which was meaningless since solver-based completion.
It then determines whether to suggest the entire function call pattern (with all argument labels) or only a single argument based on whether there are any existing arguments in the call.
For this to work properly, we need to improve parser recovery a little bit so that it parsers arguments after the code completion token properly.
This should make call pattern heuristics obsolete.
rdar://84809503
Use the PatternBindingInitializer context if we
have one. This also uncovered a parser issue where
we would mistakenly create a
PatternBindingInitializer in top-level code after
parsing the initializers.
Generate all entries, and ensure we introduce a
PatternBindingInitializer context for non-local
cases. Also use this opportunity to cleanup
`PatternBindingDecl::create`.
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.
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.
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.
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
