In most of the tests for this project, we ignore the ranges (for instance through the use of CombineTestUtil.noRangeDeclaration).
It is possible (and it has in the past) that this hides some bugs around the position of the parsed Elm code.
It would be great if we got rid of all these, and actually tested for positions, even if that makes test code harder to read and more cumbersome to write.
Another benefit is that having all the ranges means we will have regression tests that will include the ranges. Meaning that if a change in our parser ever changes the location, we will be made aware.
If anyone wants to take a look at this, that would be awesome. This could be done in steps, and doesn't need to be done in a single pass.
In most of the tests for this project, we ignore the ranges (for instance through the use of
CombineTestUtil.noRangeDeclaration). It is possible (and it has in the past) that this hides some bugs around the position of the parsed Elm code.It would be great if we got rid of all these, and actually tested for positions, even if that makes test code harder to read and more cumbersome to write.
Another benefit is that having all the ranges means we will have regression tests that will include the ranges. Meaning that if a change in our parser ever changes the location, we will be made aware.
If anyone wants to take a look at this, that would be awesome. This could be done in steps, and doesn't need to be done in a single pass.