Enable exception filters when exception patterns are simple #12737
Conversation
dsyme
changed the title
|
This is ready |
| | DebugPoints (Expr.Const _, _) -> true | ||
| | _ -> false | ||
|
|
||
| // Filters seem to generate invalid code for the ilreflect.fs backend |
| @@ -9,18 +9,22 @@ open System.Reflection | |||
| open System.Text | |||
| open System.Runtime.CompilerServices | |||
|
|
|||
| exception IllegalFileNameChar of string * char | |||
| exception internal IllegalFileNameChar of string * char | |||
There was a problem hiding this comment.
Same comment as the last pr it was in, is it possible that a compiler service developer does or could reasonably depend on this exception?
There was a problem hiding this comment.
Nope, no one will rely on this, it should never have been public
| System.Console.WriteLine() | ||
| with | ||
| | _ -> System.Console.WriteLine() | ||
| let test1() = |
There was a problem hiding this comment.
Lol ... I'm trying to kill fsharpqa and you are adding more tests to it :-).
It's fine, when I get to the emitted il tests I will move them.
Kevin
There was a problem hiding this comment.
Yup :) However note that the emitted IL tests can't be moved until we have an ILDASM that reports debug sequence points, or find some other way of taking useful baselines which include debug sequence points. fsharpqa is currently the only way we have of validating the way sequence points relate to generated IL
Yup the FCS change is ok |
Fixes #3297
F# exception handling often appears as "rethrow" in the exception debugging experience, e.g. see #3297. This is because F# doesn't routinely emit exception filters - and this is because the patterns used in exception matching might have side effects due to active patterns. On the other hand, exception filters give a much better debugging experience.
Historically we've had the hidden switch
--generate-exception-filtershowever as noted in #66 we never turned them on by default because we were concerned about side effect order and side effects happening twice.However basic pattern matches such as exception type tests are very common and in these cases we should generate a filter block.
In this PR we identify a subset of pattern matching that is side-effect free and use that to determine if we emit a filter block.
This particularly affects the experience for uncaught exceptions where a surrounding try/with fails to catch, e.g.
Before (showing the uncaught exception throwing at the "rethrow")
After (showing the uncaught exception at origin)
Codegen tests will fail and need updating