You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation of file-based versions (https://go.dev/issue/62605) uses positions to associate syntax with a per-file go version.
gopls has logic to fix syntax before type checking which likely invalidates some positions. For example, I think this manifests as #64320 (comment), where we can't position a type checker error.
This is a reminder issue that this logic may need to be more careful about preserving valid positions, such as by setting the position of synthetic syntax to the file base. Otherwise, we may produce inaccurate type checking results in the future.
Not super urgent, because at the moment there is no file version that can affect type checker rules. You can't downgrade a file to before 1.21, when the semantics of file versions changed.
Putting this in firstname.lastname@example.org, though if this slips to v0.17 that's OK.
In golang/go#64488, we observe how a seemingly innocuous change to
postfix completion tests led to significant flakiness in our integration
tests, which started to encounter a new bug.Report for out-of-bounds
positions on type checker errors.
The root cause is that the new syntax of the test data triggered AST
fixes (i.e. parsego.fixAST) that overflowed the original file. The
failure was not deterministic because the postfix snippet tests do not
wait for diagnostics: adding an env.AfterChange() to the end of the test
body made the failure deterministic.
Additionally, while investigating I encountered and fixed a clear bug
that fixes (and therefore parsego.File.Fixed()) were not correctly
counted. This was incidental, and did not contribute to the test
failures. We don't actually use Fixed() very much, though we probably
should consider it more.
To fix the underlying bug, clamp positions to the token.File. This is
definitely unsatisfactory, but after an hour of tracing through the fix
logic, I am hesitant to commit to a more principled yet risky change.
This logic is rather tricky and clearly contains a lot of embedded
knowledge. It's probably best to leave it alone and redirect efforts to
improved parser recovery.
This is strong evidence that at some point we do need to carefully
scrutinize the AST fixes (see also golang/go#64335).
Auto-Submit: Robert Findley <email@example.com>
LUCI-TryBot-Result: Go LUCI <firstname.lastname@example.org>
Reviewed-by: Alan Donovan <email@example.com>