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.
wasn't being detected while parsing operator decls, and so declarations of
invalid operators would be accepted without error and then later couldn't
be used.
Now errors correctly and new tests added.
UnconditionalAvailabilityKind => PlatformAgnosticAvailabilityKind
::UnavailableInCurrentSwift => ::SwiftVersionSpecific
Plus a couple related method renamings. Prep work for SR-2709.
[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) {}
^
_:
By consuming parens.
As for type attributes, handle `@unknownAttribute(Arg) -> Ret` case.
Improves diagnostic QoI. For example, on:
func foo(x: @unknown(x) Int) {}
Before:
test.swift:1:14: error: unknown attribute 'unknown'
test.swift:1:25: error: expected ',' separator
test.swift:1:25: error: unnamed parameters must be written with the empty name '_'
test.swift:1:22: error: use of undeclared type 'x'
Now, we just emit the first one:
test.swift:1:14: error: unknown attribute 'unknown'
func foo(x: @unknown(x) Int) {}
^
`@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.
The scope map relies fairly deeply on having reasonable source ranges
for AST nodes. Fix the construction and query of source ranges in a
few places throughout the parser and AST to provide stronger
invariants.
We were optimizing away unused pattern binding initializer contexts in
both the parser and in semantic analysis, which led to a
somewhat-unpredictable set of DeclContexts in the AST. Normalize
everything by always creating these contexts.
* [Parser] Preserve empty getter functions to make sure indentation inside its body still works. rdar://28049927
* Using the consistent identifier even though they are identical.
* If "required" or "convenience" is specified, emit only initializers
* If "final" or "open" is specified, don't emit initializers or typealias
* If "typealias" is specified, emit only associated type implementation
* Emit "override" or "required" modifier for initializers
* Emit access modifier for initializers
* Emit designated initializers even if "override" is specified
* Don't emit inheritance clause for associated type implentation
When replace something with a punctuator, we often prefer adding spaces around it.
For instance,
func foo(): bar {}
// fix it
func foo() -> bar {}
In this case we want to add a space before '->', but not after that.
With this change, we can simply `fixItReplace(ColonLoc, " -> ")`.
`fixItReplace()` automatically adjust the spaces around it.
And improve the error message for non-empty braces; if we're going to
ignore the contents, we should at least point you in the right
direction for Swift 3.
rdar://problem/27576922
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
It looks like migration fixits are done, and this doesn't
expose any new bugs that were not possible before, because
you could already define typealiases inside protocol
extensions.
To prevent some compiler_crasher regressions, add a simple
circularity-breaking hack. I'll need to do a sweep to clean
these up some day soon.
