go/parser: StructType.End() can underflow the File

[adonovan]

A struct type with a missing close brace has an StructType.End pos of zero. That means the enclosing nodes such as ReturnStmt may also have a computed End that is zero, or perhaps slightly larger:

I believe this is the root cause of at least some of the many gopls crashes recorded in #64547.

Ultimately this is a problem of parser error recovery. We need to establish the invariants that:

• all tree nodes have valid Pos/End positions; and
• all tree nodes have nested Pos/End subranges (with a possible exception for the func keyword in FuncDecl/FuncType).

See also:

• go/parser: StructType.End() can overflow the File #48300 ;-)

[gopherbot]

Change https://go.dev/cl/576655 mentions this issue: gopls/internal/cache: analysis: repair start/end and refine bug report

[findleyr]

Let's try to fix this for Go 1.23. Adding to the milestone.

[gopherbot]

Change https://go.dev/cl/577595 mentions this issue: [gopls-release-branch.0.15] gopls/internal/cache: analysis: repair start/end and refine bug report

[adonovan]

@findleyr suggests that a fuzzer connected to an invariant checker would be a good source of regression test cases.

[findleyr]

Shall we expand this issue to introducing and enforcing our stated invariant?

[adonovan]

Shall we expand this issue to introducing and enforcing our stated invariant?

Perhaps we need an umbrella issue. See also #66790 (comment), which is the beginning of a theory of pos/end in ill-formed trees.