Create some unit tests for Doc syntax #5376
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously it would trim the first and last `Lexeme` from the actual result, to avoid having to include the extra “file” `Open`/`Close` in the expected value. However, when lexing failed, you’d just get a mismatch against an empty list of tokens. This now adds `Open`/`Close` to expected before comparing, and reports lexing failures differently.
This does all `Doc` annotations with `Cofree`. As a consequence, some types have been broken apart and constraints that were mentioned in comments before are now encoded in the types. The only remaining direct recursion is now between `Column` and `List`. This is a precursor for unit testing Doc parsing, as this allows us to drop all annotations from the Doc structure, making it much less fragile.
Have them alongside the Doc parser tests, rather than embedded in `Main`.
aryairani
approved these changes
Sep 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Overview
The goal of this is faster testing cycles and more precise test cases than using transcripts. However, there is a bunch of background work to make it work. Most notably it
unison-util-recursionpackage to unify the recursion-schemey code around the repo andTokenis removed from the lexer tests).Implementation notes
This takes more advantage of fixed-point operators to allow changing the structure more easily (dropping annotations for test cases).
The Doc restructuring also encodes more of the restrictions in types (which had previously been in comments). We don’t want to keep those restrictions, but they reflect what the parser is currently able to parse.
This PR also changes the lexer unit tests a bit to catch some failures that could previously be missed. E.g., since it dropped the first and last token of the actual result (to match the provided expected result), an
Errlexeme could be dropped, making a failure look like a success when compared against an empty expected result, or at least obscuring the reason for a failure.Interesting/controversial decisions
I don’t know … recursion schemes? Although they’re already used in a few places, like the ABTs.
Test coverage
This adds a bunch of new unit tests, but none of them are particularly interesting, just a few to justify the existence of the new test suite.
Loose ends
Moar tests in the suite, that focus on edge cases. But with upcoming changes like #5255, it seems premature to try to explore the boundaries of the current syntax.