Add an option to the lexer to go back and get a list of "full"
tokens, which include their leading and trailing trivia, which
we can index into from SourceLocs in the current AST.
This starts the Syntax sublibrary, which will support structured
editing APIs. Some skeleton support and basic implementations are
in place for types and generics in the grammar. Yes, it's slightly
redundant with what we have right now. lib/AST conflates syntax
and semantics in the same place(s); this is a first step in changing
that to separate the two concepts for clarity and also to get closer
to incremental parsing and type-checking. The goal is to eventually
extract all of the syntactic information from lib/AST and change that
to be more of a semantic/symbolic model.
Stub out a Semantics manager. This ought to eventually be used as a hub
for encapsulating lazily computed semantic information for syntax nodes.
For the time being, it can serve as a temporary place for mapping from
Syntax nodes to semantically full lib/AST nodes.
This is still in a molten state - don't get too close, wear appropriate
proximity suits, etc.
This biggest change is:
- LayoutConstraintInfo is now a FoldingSetNode, which allows for proper canonicalization of LayoutConstraints. This is important for the correctness of type comparisons if types contain layout constraints.
No functionality changes from the client's point of view.
Add diagnostics to fix decls with consecutive identifiers. This applies to
types, properties, variables, and enum cases. The diagnostic adds a camel-cased option if it is different than the first option.
https://bugs.swift.org/browse/SR-3599
The new `@_specialize` attribute has a syntax like this:
```swift
@_specialize(exported: true, kind: full, where K == Int, V == Int)
@_specialize(exported: false, kind: partial, where K: _Trivial64)
func dictFunction<K, V>(dict: Dictionary<K, V>) {
}
```
If `exported` is set, the corresponding specialization would have a public visibility and can be used by clients.
If `exported` is omitted, it's value is assumed to be `false`.
If `kind` is `full` it means a full specialization.
If `kind` is `partial` it means a partial specialization.
If `kind` is omitted, its value is assumed to be `full`.
Parsing declaration list (e.g. member list of nominal decl) is very
different from comma separated list, because it's elements are separated with
new-line or semi-colon. There's no good reason to consolidate them.
Also, declaration list in 'extension' or inside of decl '#if' didn't
emit diagnostics for consecutive declarations on a line.
class C {
#if true
var value: Int = 42 func foo() {}
#endif
}
extension C {
func bar() {} subscript(i: Int) -> Int {
return 24
}
}
This change consolidates declaration list parsing for
members of nominal decls, extensions, and inside of '#if'.
In addition, removed unnecessary property 'TrailingSemiLoc' from decl.
This reverts the contents of #5778 and replaces it with a far simpler
implementation of condition resolution along with canImport. When
combined with the optimizations in #6279 we get the best of both worlds
with a performance win and a simpler implementation.
This completely removes Parse’s ability to make any judgement calls
about compilation conditions, instead the parser-relevant parts of
‘evaluateConditionalCompilationExpr’ have been moved into
‘classifyConditionalCompilationExpr’ where they exist to make sure only
decls that we want to parse actually parse later.
The condition-evaluation parts have been moved into NameBinding in the
form of a Walker that evaluates and collapses IfConfigs. This walker
is meant as an homage to PlaygroundLogger. It should probably be
factored out into a common walker at some point in the future.
Implemented in the naive way by way of the current ASTContext’s
‘LoadedModules’. In theory this list should be in one-to-one
correspondence with the definition of “importable” as any module that
is required for compilation is loaded *before* we start parsing the
file. This means we don’t have to load the module, just check that
it’s in the set of loaded modules.
Note that this approach will most likely fall apart if submodules are
introduced and are lazily loaded. At that point this will need to be
refactored into a format that defers the checking of conditions
sometime before or during typechecking (after namebinding).
* Removed `parseConstructorArguments()`, unified with
`parseSingleParameterClause()`.
* Use `parseSingleParameterClause()` from `parseFunctionSignature()`, so
that we can share the recovery code.
* Removed `isFirstParameterClause` parameter from `mapParsedParameters`,
because it's predictable from `paramContext`.
Use a syntax that declares the layout's generic parameters and fields,
followed by the generic arguments to apply to the layout:
{ var Int, let String } // A concrete box layout with a mutable Int
// and immutable String field
<T, U> { var T, let U } <Int, String> // A generic box layout,
// applied to Int and String
// arguments
These APIs return SourceLocs, and eventually the Parser should consume
tokens, which now include source trivia such as whitespace and comments,
and package them into a purely syntactic tree. Just a tiny step. NFC.
Store leading a trailing "trivia" around a token, such as whitespace,
comments, doc comments, and escaping backticks. These are syntactically
important for preserving formatting when printing ASTs but don't
semantically affect the program.
Tokens take all trailing trivia up to, but not including, the next
newline. This is important to maintain checks that statements without
semicolon separators start on a new line, among other things.
Trivia are now data attached to the ends of tokens, not tokens
themselves.
Create a new Syntax sublibrary for upcoming immutable, persistent,
thread-safe ASTs, which will contain only the syntactic information
about source structure, as well as for generating new source code, and
structural editing. Proactively move swift::Token into there.
Since this patch is getting a bit large, a token fuzzer which checks
for round-trip equivlence with the workflow:
fuzzer => token stream => file1
=> Lexer => token stream => file 2 => diff(file1, file2)
Will arrive in a subsequent commit.
This patch does not change the grammar.
Like cursor-info, range info (""source.request.cursorinfo"") answers some
questions clients have for a code snippet under selection, for instance, the type of a selected
expression. This commit implements this new quest kind and provides two
simple information about the selected code: (1) the kind of the
snippet, currently limited to single-statement and expression; and (2)
the type of the selected expression. Gradually, we will enrich the
response to provide more insight into the selected code snippet.
Now 'P1 & P2.Type' is parsed as (composition P1, (metatype P2))
instead of (metatype (composition P1, P2)).
For now, parsing inheritance clause accepts any TypeRepr, that is not allowed
in current Swift grammer. Diagnostic logic will be added in later commits.
Also, in Swift3, (composition P1, (metatype P2)) should be fixed to
(metatype (composition P1, P2)) for source compatibility.
And make it be able to composite any TypeReprs.
Although Swift doesn't support composition of arbitrary types, AST
should be able to hold any TypeReprs, to represent syntax as accurate as
possible.
[SourceKit] Indentation: when the indented line starts with open brace and the
line before starts with a leading declaration keywords, we never add
indentation level on the brace. rdar://28049927
