-
Notifications
You must be signed in to change notification settings - Fork 153
EH: Implement support for filters in reader #74
Comments
I'm working on getting filter outlining working in the EH branch in the Sprint 85 timeframe. |
This is checked in to the EH branch (commit 065c618). I'm clearing the milestone label but leaving the issue open to track merging it into master (and updating it to the new EH representation) |
Should this now be closed? The EH branch has been merged. |
What got merged in with the EH branch for filters was a workaround that translates them into a catch with explicit rethrow. The workaround is semantically incorrect because it delays the evaluation of the filter expression to the 2nd pass of expression unwinding (it's supposed to happen in the 1st pass), though I expect typical filter usage won't notice that difference. The workaround is also undesirable from a debugging perspective, because any exception that a filter declines to handle will effectively have its stack trace truncated when it is ultimately handled (with the frames below the filter missing). So I thought it made sense to leave this open to track implementing full filter support rather than the workaround (which likely requires expanding LLVM's ability to represent filters first; Clang can represent semantics correctly currently by outlining filter expressions, but that outlining is not a viable option for LLILC due to some constraints the runtime has on how filters are reported). |
Correction: the rethrow used by the workaround does not truncate stack traces. So really the sole issue is delaying filter expressions to the 2nd pass. And to clarify that: the issue is specifically regarding cases where an exception is raised inside a try protected by a finally/fault which itself is inside a try (possibly in a different call frame) protected by a filter, with no intervening catches -- the filter expression should be evaluated before the finally/finallies execute, but with the workaround will be evaluated after. |
Note: this is a much larger task than for the other handler types, because it requires outlining the filter function.
Part of #13.
The text was updated successfully, but these errors were encountered: