Report unterminated construct errors at opening token

[thomasmarshall]

👋 We're working on integrating Prism into Sorbet and I would like to propose an improvement to how unterminated construct errors are reported to end users.

This PR adds an expect1_opening function that expects a token and attaches the error to the opening token location rather than the current position. This is useful for errors about missing closing tokens, where it could be useful to point to the line with the opening token rather than the end of the file.

For example:

def foo
def bar
def baz
       ^ expected an `end` to close the `def` statement
       ^ expected an `end` to close the `def` statement
       ^ expected an `end` to close the `def` statement

This would previously produce three identical errors at the end of the file. After this commit, they would be reported at the opening token location:

def foo
^~~ expected an `end` to close the `def` statement
def bar
^~~ expected an `end` to close the `def` statement
def baz
^~~ expected an `end` to close the `def` statement

This way, end users can see which particular def node is considered unclosed, rather than a seeing a collection of errors all pointing to the end of the file. However, I understand this might be considered less technically correct and potentially less useful in certain situations. In the single-line test examples it might seem preferable to show the error at end-of-input, since that's where the closing token should be, but I think in most practical cases that won't be the case.

Alternative

An alternative approach might be to add "hints" to errors so the error location remains end-of-input but an additional hint location could point to the opening token. Clients could choose whether to surface the original error location, the hint location, or both. What do you think?

Tests

As part of this, I added a handful of tests capturing the original behavior which should make it easier to see the effect this proposed change has.

[kddnewton]

This is great, I love it.

Yeah in reality this is showing a limitation of our error messages where they only refer to a single location. Other languages have more sophisticated setups where it can refer to an origination point as well as when the error was detected, which is really what we should work toward. But I think this is a really good step in that direction (especially because it finds all of the call sites for us to extend later).