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.
Merge `$<Feature>` and `hasFeature` implementations.
- `$<Feature>` did not support upcoming language features.
- `hasFeature` did not support promoted language features and also
didn't take into account `Options` in `Features.def`.
Remove `Options` entirely, it was always one of three cases:
- `true`
- `langOpts.hasFeature`
- `hasSwiftSwiftParser`
Since `LangOptions::hasFeature` should always be used anyway, it's no
longer necessary. `hasSwiftSwiftParser` can be special cased when adding
the default promoted language features (by removing those features).
Resolves rdar://117917456.
Generate all entries, and ensure we introduce a
PatternBindingInitializer context for non-local
cases. Also use this opportunity to cleanup
`PatternBindingDecl::create`.
