Skip to content
This repository has been archived by the owner on Mar 15, 2022. It is now read-only.

EH: Implement support for filters in reader #74

Closed
JosephTremoulet opened this issue Feb 19, 2015 · 5 comments
Closed

EH: Implement support for filters in reader #74

JosephTremoulet opened this issue Feb 19, 2015 · 5 comments

Comments

@JosephTremoulet
Copy link
Contributor

Note: this is a much larger task than for the other handler types, because it requires outlining the filter function.

Part of #13.

@JosephTremoulet
Copy link
Contributor Author

I'm working on getting filter outlining working in the EH branch in the Sprint 85 timeframe.

@JosephTremoulet JosephTremoulet modified the milestones: Sprint 86, Sprint 85 Jul 2, 2015
@JosephTremoulet JosephTremoulet removed this from the Sprint 86 milestone Jul 13, 2015
@JosephTremoulet
Copy link
Contributor Author

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)

@DemiMarie
Copy link

Should this now be closed? The EH branch has been merged.

@JosephTremoulet
Copy link
Contributor Author

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).

@JosephTremoulet
Copy link
Contributor Author

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.

@JosephTremoulet JosephTremoulet removed their assignment Sep 14, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants