* libSyntax: Parse member access expression.
This patch uses createNodeInPlace from syntax parsing context API to
merge an expression with its suffix to create recursive nodes such as
member access expression.
Meanwhile, this patch breaks down a signed integer or float literal to a
prefix operator expression. This expression consists of two parts: an
operator and the following expression. This makes literals like "+1" or
"-1" no different from other prefix unary expressions such as "!true".
This commit also adds ArrayExpr and DictionaryExpr to the libSyntax nodes
family. Also, it refactors the original parser code for these two
expressions to better fit to the design of SyntaxParsingContext.
This commit has also fixed two crashers.
This commit teaches parser to parse two libSyntax nodes: FunctionCallArgument and
FunctionCallArgumentList. Along with the change, some libSyntax parsing infrastructure changes
as well: (1) parser doesn't directly insert token into the buffer for libSyntax node creation;
instead, when creating a simple libSyntax node like integer literal expression, parser should indicate the location of the last token in the node; (2) implicit libSyntax nodes like empty
statement list must contain a source location indicating where the implicit nodes should appear
(immediately before the token at the given location).
* Re-apply "libSyntax: Ensure round-trip printing when we build syntax tree from parser incrementally. (#12709)"
* Re-apply "libSyntax: Root parsing context should hold a reference to the current token in the parser, NFC."
* Re-apply "libSyntax: avoid copying token text when lexing token syntax nodes, NFC. (#12723)"
* Actually fix the container-overflow issue.
This patch allows Parser to generate a refined token stream to satisfy tooling's need. For syntax coloring, token stream from lexer is insufficient because (1) we have contextual keywords like get and set; (2) we may allow keywords to be used as argument labels and names; and (3) we need to split tokens like "==<". In this patch, these refinements are directly fulfilled through parsing without additional heuristics. The refined token vector is optionally saved in SourceFile instance.
We can just use parseType() everywhere instead. We already check
for non-identifier types in inheritance clauses elsewhere, and indeed
we have to anyway because an identifier type might resolve to a
type alias whose underlying type is a non-nominal type.
It doesn't look like this change made any diagnostics worse, but if
we find a case where it did, we could revert it.
We had two slightly different codepaths to diagnose ': class'
in an inheritance clause where it is not supported.
For generic parameters, we would fix the 'class' to 'AnyObject',
but for associated types we didn't do this. Perform the fix in
all cases where it makes sense and remove one of the two
diagnostics.
This fixes various issues with getting no code-completion in top-level
code containing array/dictionary sugar, such as:
```
for x in [<HERE>] {}
for x in [1: 2, <HERE>] {}
```
And also removes the index variable from completions inside the sequence
(it was coming through as a local variable with <<error type>>).
rdar://problem/33884082
* Generate libSyntax API
This patch removes the hand-rolled libSyntax API and replaces it with an
API that's entirely automatically generated. This means the API is
guaranteed to be internally stylistically and functionally consistent.
...finally breaking the dependency of Parse on Sema.
There are still some unfortunate dependencies here -- Xi's working on
getting /AST/ not dependent on Sema -- but this is a step forward.
It is a little strange that parseIntoSourceFile is in ParseSIL, and
therefore that that's still a dependency for anyone trying to, well,
parse. However, nearly all clients that parse want to type-check as
well, and that requires Sema, Serialization, and the ClangImporter...
and Serialization and SIL currently require each other as well
(another circular dependency). So it's not actively causing us trouble
right now.
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
Resolves: https://bugs.swift.org/browse/SR-4426
* Make IfConfigDecl be able to hold ASTNodes
* Parse #if as IfConfigDecl
* Stop enclosing toplevel #if into TopLevelCodeDecl.
* Eliminate IfConfigStmt
This introduces a few unfortunate things because the syntax is awkward.
In particular, the period and following token in \.[a], \.? and \.! are
token sequences that don't appear anywhere else in Swift, and so need
special handling. This is somewhat compounded by \foo.bar.baz possibly
being \(foo).bar.baz or \(foo.bar).baz (parens around the type), and,
furthermore, needing to distinguish \Foo?.bar from \Foo.?bar.
rdar://problem/31724243
Fixes:
https://bugs.swift.org/browse/SR-3455https://bugs.swift.org/browse/SR-3663https://bugs.swift.org/browse/SR-4032https://bugs.swift.org/browse/SR-4031
Now, compilation conditions are validated at first, then evaluated. Also,
in non-Swift3 mode, '&&' now has higher precedence than '||'.
'A || B && C || D' are evaluated as 'A || (B && C) || D'.
Swift3 source breaking changes:
* [SR-3663] This used to be accepted and evaluate to 'true' because of short
circuit without any validation.
#if true || true * 12 = try Anything is OK?
print("foo")
#endif
In this change, remaining expressions are properly validated and
diagnosed if it's invalid.
* [SR-4031] Compound name references are now diagnosed as errors.
e.g. `#if os(foo:bar:)(macOS)` or `#if FLAG(x:y:)`
Swift3 compatibility:
* [SR-3663] The precedence of '||' and '&&' are still the same and the
following code evaluates to 'true'.
#if false || true && false
print("foo")
#endif
foo(_: 3) is equivalent to foo(3), so calling a function that has _ as
an argument label (func foo(`_`: 3)) still requires the _ to be
escaped. Before this patch, the compiler would suggest removing the `s,
even though that changes behaviour.
Fixes rdar://problem/31077797.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
