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

Jump to bottom

Location in the mli when an implementation doesn't match its interface #6853

Closed
vicuna opened this issue Apr 28, 2015 · 4 comments
Closed

Location in the mli when an implementation doesn't match its interface #6853

vicuna opened this issue Apr 28, 2015 · 4 comments
Labels
bug suspended typing

Comments

@vicuna
Copy link

vicuna commented Apr 28, 2015

Original bug ID: 6853
Reporter: @Drup
Status: closed (set by @alainfrisch on 2015-04-28T16:52:19Z)
Resolution: suspended
Priority: normal
Severity: minor
Version: 4.02.1
Category: typing

Bug description

When the implementation of a toplevel declaration doesn't match the type in the .mli, the location of the declaration in the .ml is provided (which is great) but not the one in the .mli ! It would be nice to have that.
@vicuna
Copy link
Author

vicuna commented Apr 28, 2015

Comment author: @lpw25

IIRC the -keep-locs options enables this behaviour

@vicuna
Copy link
Author

vicuna commented Apr 28, 2015

Comment author: @Drup

Hum I see, thanks. What are the other consequences of this option (and why is it not by default) ?

I guess I will add it to all my projects. :)

@vicuna
Copy link
Author

vicuna commented Apr 28, 2015

Comment author: @dbuenzli

drup, see the discussion in #6311#c13595

@vicuna
Copy link
Author

vicuna commented Apr 28, 2015

Comment author: @Drup

Thanks. I don't have any more arguments to bring to the discussion, but I mostly agree with you. It should be the default.

@vicuna vicuna closed this as completed Apr 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug suspended typing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@vicuna