Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow exception-patterns under or-patterns #1568

Merged
merged 4 commits into from
Jul 16, 2018

Conversation

trefis
Copy link
Contributor

@trefis trefis commented Jan 15, 2018

Revival of #305 .

A few things of note compared to the previous version:

  • Parmatch and Matching always assert false when they see a Tpat_exception
  • Parmatch.pressure_variants is called on the value and exception patterns independently.
    This wasn't done in the previous version and was the cause of PR#7083.
  • Parmatch.check_ambiguous_bindings is called independently on the value and exception patterns. As for the other operations in parmatch, it wouldn't make sense to mix both kind of patterns in a single matrix.
  • In Rec_check I believe I handle cases containing only exception-patterns in exactly the same way as before. However, I wonder if perhaps this special casing could not simply be dropped (considering that Tpat_exception is not a destructuring pattern). I didn't try to understand how the check works though (nor do I plan to right now) so I'm going to leave things as is unless @yallop says it can be simplified.
  • in Translcore I make sure to remember (i.e. save in try_ids) all the names given to the exception of an exception pattern so that reraise works properly. I also added a test to make sure reraise works as intended when raising from a branch when we either match or catch an exception.

Apart from that everything should be as in #305, in particular : mixing value and exception patterns under a guard is still disallowed.


Off-topic:

  • I noticed that Parmatch.check_ambiguous_bindings is delayed when the matching contains polymorphic variants (and I didn't change it here) but I don't think that is necessary.
  • This PR is based on top of Register all idents relevant for reraise. #1567 , so the first 3 commits can be disregarded.

@@ -2824,6 +2825,7 @@ let find_in_pat pred =
find_rec p || find_rec q
| Tpat_constant _ | Tpat_var _
| Tpat_any | Tpat_variant (_,None,_) -> false
| Tpat_exception _ -> assert false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an indentation issue or did it mean something else ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like indentation/copy-paste failure on my part; it's now fixed.

Thanks!

hhugo added a commit to ocsigen/js_of_ocaml that referenced this pull request Jan 16, 2018
Generated with ocaml/ocaml#1568

$ cat test3.ml
exception A of int

let y =
  match Random.int 2 with
  | 0 as i | exception A (2 as i) -> i
  | i -> i+1
  | exception A i -> i+2

$ cat test4.ml
exception A of int

let y =
  match Random.int 2 with
  | 0 as i | exception A (2 as i) -> i
  | i -> i+1

jbuilder build compiler/js_of_ocaml.bc && _build/default/compiler/js_of_ocaml.bc --debug main test3.cmo
assert false

jbuilder build compiler/js_of_ocaml.bc && _build/default/compiler/js_of_ocaml.bc --debug main test4.cmo
stackoverflow
@trefis
Copy link
Contributor Author

trefis commented Jan 22, 2018

Rebased, as #1567 is now on top of #1573, the first 5 commits can be ignored.
The tests should now pass on both linux and windows!

@trefis
Copy link
Contributor Author

trefis commented Feb 19, 2018

I just rebased this PR on trunk now that the #1573 and #1567 have been merged. This should therefore be much easier to review.

Also, it should be noted that js_of_ocaml has been updated to handle exceptions under or-patterns!

@trefis trefis requested a review from gasche February 19, 2018 11:55
@trefis trefis force-pushed the or-exception-2018 branch 2 times, most recently from 757ca8d to 2834938 Compare June 13, 2018 11:03
@trefis
Copy link
Contributor Author

trefis commented Jun 13, 2018

I rebased this once more!

I also pinged @gasche by email to get some review, who (for obscure reasons) said it wasn't reasonable (sic) for him to review this.
So let me repeat some of my earlier points and ping some people explicitly:

  • testsuite/tests/match-exception-warnings/placement.ml tests all the syntactically valid patterns involving a Ppat_exception.
    In particular one can see that exception patterns are now allowed under: or-patterns, local opens, type constraints. And that's the only change, every other appearance is still rejected.
  • Rec_check has been updated.
    I suspect that the changes are correct but could be simplified. I would very much appreciate a review from @yallop on this.
  • Parmatch will error out (assert false or fatal_error) if it ever sees a Tpat_exception: there is no real need for review here (but the callers must be checked).
  • The compilation (most of the changes happening in Translcore) is as it was in Support "exception" under or-patterns (PR#6422) #305 .
    I still believe it is fine, but a fresh review from @chambart or @maranget can't hurt.
  • The changes in Typecore are the ones that need review the most: they aren't that big, but that's where the issue was missed last time. The changes to type_pat are fairly trivial, but a complete review type_cases is required.
    @garrigue , @lpw25: would one of you mind giving it a look?

@yallop
Copy link
Member

yallop commented Jun 22, 2018

In Rec_check I believe I handle cases containing only exception-patterns in exactly the same way as before. However, I wonder if perhaps this special casing could not simply be dropped (considering that Tpat_exception is not a destructuring pattern). I didn't try to understand how the check works though (nor do I plan to right now) so I'm going to leave things as is unless @yallop says it can be simplified.
[...]
I suspect that the changes are correct but could be simplified.

Yes -- it looks to me as though is_exception_pattern could be dropped altogether, leaving the code in case as it was previously.

dra27
dra27 previously requested changes Jun 30, 2018
Copy link
Member

@dra27 dra27 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excuse the nit, which is #1148-related

flags = "-g"
ocamlrunparam += ",b=1"
* bytecode
reference = "${test_source_directory}/backtrace_or_exception.byte.reference"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is over 80 chars!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not anymore! :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thank you - now that the an off-by-one error in the Travis CI script is fixed, it'll even get scanned next time 🙂

@trefis
Copy link
Contributor Author

trefis commented Jul 2, 2018

@yallop: thanks! I pushed a commit doing the simplification.

@dra27 dra27 dismissed their stale review July 3, 2018 12:12

check-typo changes dealt with

Copy link
Contributor

@lpw25 lpw25 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reviewed the type-checking stuff and it looks fine. Since the other parts have already been reviewed, I think this is ready to merge.

@trefis
Copy link
Contributor Author

trefis commented Jul 13, 2018

Thanks for the review!

I'll rebase and merge this on Monday, unless someone objects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants