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 complete reimplementation of #43 with the following changes:
The first attempt couldn't cope with, say,
opam-version: "42" <
because the parsing error occurs before theVariable
has been completely parsed. This revised version instead reads three tokens from the lexer and so "sniff" theopam-version
before parsing starts. With this approach, there's no need to do all of the global state mucking around - we already know if the opam file is a "future" one and so any exception can instead just return theopam-version
line we successfully parsed. In order to allow a future version of opam to intentionally stick with an old parser (e.g. because opam 2.2 adds no new lexing/parsing rules), as well as theopam-version
item, a sentinel section of kind#
is returned which opam can then use to determine that there was actually a parse error.Finally, I thought of a devious, yet curiously actually valid, way of raising
OpamLexer.Error
fromOpamBaseParser.main
which means thatopam-version
in the wrong place now includes a description of the problem rather than just "parse error".