pattern-matching refactoring: first-order representation for failure handlers#9647
Conversation
|
The CI shows test failures that reveal that improving the location of I will have to go back to a dummy location there, with an explanation for why this is actually intentional. (I may still ask for a location in the interface, in case this evolves to be useful for other things later.) Ideally we would have a primitive that takes a proper location (for various debugging purposes) but doesn't add it to the backtrace, but this does not seem to exist now. |
6da72d9 to
878e73f
Compare
|
I updated the PR to not use the refined location in reraise failure-handlers, and document why we do this. |
|
This pattern-matching refactoring PR is still open. Anyone is free to help reviewing it! |
Octachron
left a comment
There was a problem hiding this comment.
Rereading this PR, the change is both correct and mundane. However, the code ends up being slightly more self-documenting. Conclusion, the PR seems fine to me.
878e73f to
954f33b
Compare
|
Thanks! This PR is a useful step towards #9651, which would itself have helped my recent work on Cannot_flatten as it simplifies |
Actually *using* the location in the failure handler would be incorrect, as it adds noise to backtraces involving partial exception handlers. This is now properly documented. We still take the caller location (which is currently ignored) for consistency with other toplevel Matching functions, and because that may become useful if we want to add more error-reporting or warnings in compile_matching.
954f33b to
fdf86ad
Compare
This PR was not initially planned in #9321, but once you get started...
(cc @trefis @Octachron)
compile_matchinguses higher-order functions to decide what code to generate for match failure. The present PR uses a proper datastructure to represent the possible cases, which simplifies the code slightly.The PR also contains a related improvement to the location used inMatching.for_trywith.