- When parsing a type or extension declaration, attempt to parse a function or property declaration when meeting an identifier, an operator or a paren (for tuple declarations).
- Produce the diagnostic with a fix-it suggesting to insert the needed keyword
- Recover parsing as if the declaration with the missing keyword is a function/property declaration
Resolves https://bugs.swift.org/browse/SR-10477
Instead of creating the AST directly in the parser (and libSyntax or
SwiftSyntax via SyntaxParsingContext), make Parser to explicitly create
a tree of ParsedSyntaxNodes. Their OpaqueSyntaxNodes can be either
libSyntax or SwiftSyntax. If AST is needed, it can be generated from the
libSyntax tree.
In parser, 'parseExprPostfixSuffix()' can parse postfix expression for
'super'. 'parseExprSuper()' doesn't need to parse them.
In code-completion, 'completeExprSuper()' and 'completeExprSuperDot()'
can be consolidated to 'completePostfixExpr()' and 'completeDotExpr()'.
```
@#^COMPLETE^#
public func something() {}
```
In this case, we can't say the user is adding attribute to the func or
starting a new declaration. So if there're one or more blank lines after the
completion, suggest context free attribute list.
rdar://problem/50441643
The diagnostic is now a warning and the new message alerts the user that
though it is valid to have let and var as argument label names,
they are interpreted as argument labels, not keywords.
Allow the use of declarations whose names start with $ in all
modes. However, normal code cannot define new entities with names that
start with $: only the implementation can do that, e.g., for property
delegates.
ParsedSyntaxBuilder has a convenient function to add member to a syntax-collection
child. The function name uses the type name of the collection's members,
which can lead to name collision. This patch renames it.
This adds an implicit body so that we can dig out the return type
context the same way as a normal function. For now, we are also treating
the first expression in a multi-statement implicit getter body the same
way; we'll need to refactor how we complete in accessors to
differentiate those cases.
When completing in the only expression of closure, use the return type
of the closure as the type context for the code-completion. However,
since code-completion may be on an incomplete input, we only use the
return type to improve the quality of the result, not to mark it
invalid, since (a) we may add another statement afterwards, or (b) if
the context type is Void it doesn't need to match the value.
This is just for use in the debugger when one may want to know what is in the
current scope. The order is not guaranteed but at least it can provide /some/
info ignoring that property. These are no-ops when not in asserts and I put in a
compile time warnign to make sure it is not used in the actual code base.
Previously, the Lexer kept a single flag whether we’re lexing Swift or SIL. Instead, keep track if we’re parsing Swift, SIL, or a Swiftinterface file. .swiftinterface files allow $-prefixed identifiers anywhere.
