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. |
gasche
force-pushed
the
rematch-matching-handler-fun
branch
from
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! |
gasche
force-pushed
the
rematch-matching-handler-fun
branch
from
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.
gasche
force-pushed
the
rematch-matching-handler-fun
branch
from
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.