SR-13098 Diagnostic improvement: encountering an unexpected statement at type scope (second PR) #34209
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a new branch to address this.
(Commit message below)
Added a simple check for a period token after the identifier to inhibit the IsProbablyFuncDecl logic.
When the parser finds an identifier at type scope it tries to determine
if it is a function declaration without the
func
keyword. Thisgenerates a cascate of diagnostics if the identifier is actually an
assignment to part of a value using the period (like a.b = 3). In this
case the parser should not try to treat is as a function and instead
just generate a simple expected declaration diagnostic.
The approach this time is to limit the change to only the case
That's the case in the examples in the bug and is straightforward to identify and handle. Earlier versions of the first pull request #32984 tried this method. The main reason we did not pursue it was because it's a limited class of errors and probing with parser functions is more general. But at the same time, probing with parser functions causes problems with performance and with maintaining the parser state correctly in some situations as @rintaro discovered.
The diagnostic cascade that is the original problem occurs when the parser is trying to emit a fix-it for a missing
func
orvar
token. If a bare identifier is in the parse stream the parser tries to generate a diagnostic for a missingfunc
. Something likefunc a.b ...
orvar a.b ...
would not be valid and we should just inhibit the check. If we inhibit the check when there's a period we go directly to theexpected declaration
diagnostic and don't get the cascade.In the original PR, one of the problems was that once we reach the
expected declaration
diagnostic the parser skips to the next right-brace, so will not emit any diagnostics for anything after the problem syntax. This is a little unfortunate but I'm not sure there's a good way to fix it. In the test there is noexpected-error
after the expected declaration.Resolves SR-13098.