Skip to content

typecore: remove redundant try … with#1881

Merged
Octachron merged 2 commits intoocaml:trunkfrom
Octachron:typecore_redundant_try_with
Jul 6, 2018
Merged

typecore: remove redundant try … with#1881
Octachron merged 2 commits intoocaml:trunkfrom
Octachron:typecore_redundant_try_with

Conversation

@Octachron
Copy link
Copy Markdown
Member

This PR proposes to remove two possibly redundant try … with clauses in typing/typecore.ml.

The first commit removes a try … with clause in the typechecking of coercion that was added while fixing MPR#7260. However, the example added with this fix does not raise such an exception.

The second commit removes the try … with clause used when typechecking local
module bindings. This clause wrap around a call to unify_var env newvar
that is called subsequently to a call to type_expect. As far as I can tell (and after a discussion with @trefis and @Drup ), this call to type_expect would have raised an exception earlier if
unify_var were to raise an exception itself, thus the try ... with statement is redundant.

This removal makes clear that the error message for locally bound module (Scoping_let_module) has been unheard of since 4.00, i.e. the prime example of this error

let module M = struct type t = A end in M.A

raises a generic scope escape message since 4.00:

Error: This expression has type M.t but an expression was expected of type 'a
The type constructor M.t would escape its scope

I have therefore updated the comment about this error message to reflect that it is currently dead code but it might be nice to restore it.

@lpw25 , @garrigue : would you have the time to comment on those minor issues?

Copy link
Copy Markdown
Contributor

@trefis trefis left a comment

Choose a reason for hiding this comment

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

I just looked at the first one with Leo today and we agree that the try with was never useful.

And as discussed previously the other one has also been unused for a while.

@trefis
Copy link
Copy Markdown
Contributor

trefis commented Jul 5, 2018

Note that I agree with your point that the error message about the scope escape could be better, but that's actually the case of all the scope escape messages, as you well know.

So I think it's fine to remove this dead code, leaving a comment explaining that the error message could be improved (which I believe you've already started working on).

@gasche
Copy link
Copy Markdown
Member

gasche commented Jul 5, 2018

Well if it is a bug to have a piece of dead code, one solution is to remove it and the other is to resurrect it. In this situation it's not clear that removing is the right thing to do, if we believe that it would be nicer to resurrect it -- removing feels like treating the symptom rather than the cure. We happen to have @Octachron around as a motivated doctor, so why not go for the right treatment right away?

@lpw25
Copy link
Copy Markdown
Contributor

lpw25 commented Jul 5, 2018

In this case, I don't think there is any benefit to trying to resurrect it. The first one has never been exercised, and I think it actually prints the wrong error message. The second one has been replaced with a better error -- the message may be more generic, but it is likely to have a much better location.

@trefis
Copy link
Copy Markdown
Contributor

trefis commented Jul 5, 2018

To clarify (because my previous message might have been unclear on that point): I don't think resurrecting the previous error would be nicer, I'm just saying that we should work towards improving scope escape error messages in general (and it is hopefully obvious to everyone why we don't do that right away).

@Octachron
Copy link
Copy Markdown
Member Author

@gasche: I don't think that the Scoping_let_module error message should be resurrected exactly as it was: what would be nice is to recover the contextual information about the local module to improve the current scope escape message.

The problem is that currently it is hard to either add such contextual information to the unification trace, or inspect the unification trace to see if the information is pertinent. I am hoping to improve this point first and only then go back to this specific error message.

It probably makes sense to remove the dead code meanwhile; I will do so in a separate PR.

@gasche
Copy link
Copy Markdown
Member

gasche commented Jul 5, 2018

ok, ok :-)

@Octachron Octachron merged commit 84872f9 into ocaml:trunk Jul 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants