Skip to content

SR-13098 Diagnostic improvement: encountering an unexpected statement at type scope (second PR) #34209

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dfsweeney
Copy link
Contributor

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. This
generates 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

struct X {
  ...
  x.y = 1
  ...
}

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 or var token. If a bare identifier is in the parse stream the parser tries to generate a diagnostic for a missing func. Something like func a.b ... or var 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 the expected 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 no expected-error after the expected declaration.

Resolves SR-13098.

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. This
generates 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.
@WowbaggersLiquidLunch
Copy link
Contributor

@swift-ci please smoke test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants