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

better location info for type errors and/or warnings in sequences & let expressions #5697

Closed
vicuna opened this issue Jul 24, 2012 · 3 comments
Closed
Assignees

Comments

@vicuna
Copy link

@vicuna vicuna commented Jul 24, 2012

Original bug ID: 5697
Reporter: Drakken
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:07:24Z)
Resolution: fixed
Priority: low
Severity: tweak
Version: 3.12.1
Category: typing

Bug description

The type checker currently reports the location of the entire body of a for loop when the body is mistyped, even though the mistake can be located more precisely for sequences and let expressions.
The included file fizzbuzz.ml has a for loop whose body contains a double let binding and a four-part sequence.
The mistake is in the last part of the sequence, where the call to print_newline is missing its unit argument. (oops! :)
The location of the current type warning unnecessarily contains all six lines
of the body, including both the let bindings and the entire sequence.

Steps to reproduce

Compile fizzbuzz.ml and examine the location info
in the warning message:

$ ocamlc fizzbuzz.ml
File "fizzbuzz.ml", line 5, characters 2-176:
Warning 5: this function application is partial,
maybe some arguments are missing.

Additional information

Patch is in included file typecore.ml.diff.

Improved output refers to only the faulty subexpression:

$ ocamlc fizzbuzz.ml
File "fizzbuzz.ml", line 10, characters 2-15:
Warning 5: this function application is partial,
maybe some arguments are missing.

Notes:

  • The function type_approx does something similar.
  • type_exp and other functions might also benefit from this.
  • I have no idea whether the function final_subexpression
    belongs somewhere else.
  • Feel free to change the name "final_subexpression" if
    you don't like it.

File attachments

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 24, 2012

Comment author: @alainfrisch

Thanks! Committed to trunk (rev 12763), also treating other cases (if, try, match).

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 24, 2012

Comment author: Drakken

Thanks, frisch. What about 4.00?

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 24, 2012

Comment author: @alainfrisch

4.00 is almost out. It's too late to add anything to it, except maybe fixes for serious bugs.

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

Successfully merging a pull request may close this issue.

None yet
2 participants