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.
* 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.
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
`InParam` was not used at all.
`StopAtTypeAttributes`
As far as I understand, this option *was* merely for improving diagnostic QoI
for declarations like:
func foo(@typeattr Arg) {}
to fix-it to:
func foo(_: @typeattr Arg) {}
But, this causes the very loudy diagnostics for misplaced type attributes.
For example, on:
func foo(@convention(block) x: () -> CInt) {}
test.swift:1:10: error: expected parameter name followed by ':'
test.swift:1:10: error: expected ',' separator
test.swift:1:10: error: expected ')' in parameter
test.swift:1:9: note: to match this opening '('
test.swift:1:10: error: consecutive statements on a line must be separated by ';'
test.swift:1:11: error: attribute can only be applied to types, not declarations
test.swift:1:21: error: expected declaration
test.swift:1:44: error: statement cannot begin with a closure expression
test.swift:1:44: note: explicitly discard the result of the closure by assigning to '_'
test.swift:1:44: error: braced block of statements is an unused closure
test.swift:1:6: error: expected '{' in body of function declaration
test.swift:1:44: error: expression resolves to an unused function
Now, we emit more accurate diagnostic:
test.swift:1:11: error: attribute can only be applied to types, not declarations
func foo(@convention(block) x: () -> CInt) {}
^
Note that This causes small regression in diagnostics for bare type parameter
like `func foo(@convention(c) () -> CInt) {}`:
Before:
test.swift:1:10: error: unnamed parameters must be written with the empty name '_'
func foo(@convention(block) () -> CInt) {}
^
_:
Now:
test.swift:1:11: error: attribute can only be applied to types, not declarations
func foo(@convention(block) () -> CInt) {}
^
test.swift:1:29: error: unnamed parameters must be written with the empty name '_'
func foo(@convention(block) () -> CInt) {}
^
_:
`@foo=bar` style attributes are no longer supported anyway.
So as ',' separated attribute list.
In `canParseTypeTupleBody()`, `canParseType()` can more accurately consume
type attributes.
In `isStartOfGetSetAccessor`, we can trivially inline the functionality.
Use tok::NUM_TOKENS instead. tok::unknown can easily appear in source code.
For instance `skipUntil(tok::eof)` did not work as expected, because that was
`skipUntil(tok::eof, tok::unknown)` hence does stop at error tokens such as
`0xG` (invalid hex number literal).
Revert 2abc92bbb5, since that was
accidental side-effect of 45118037cc.
Forward references are not allowed actually.
* [Parse] Remove unused GreaterThanIsOperatorRAII. NFC
Last usage was removed in 68af974227.
* [Parse] Remove unused ArgumentIsParameter flag. NFC
Last usage was removed in 4e4173f2e6
