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

Error location output not supported by emacs #5070

Closed
vicuna opened this issue Jun 13, 2010 · 9 comments
Closed

Error location output not supported by emacs #5070

vicuna opened this issue Jun 13, 2010 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Jun 13, 2010

Original bug ID: 5070
Reporter: palomer
Assigned to: @damiendoligez
Status: assigned (set by @damiendoligez on 2012-08-08T15:21:00Z)
Resolution: open
Priority: normal
Severity: minor
Version: 3.11.2
Category: compiler driver
Has duplicate: #6518
Related to: #4659 #5044
Monitored by: @Chris00

Bug description

if I compile the following:

let foo : int =
"foo"
^
"bar"

it gives me the error

File "/home/palomer/temp/test.ml", line 2, characters 1-21:
...

when the next-error function in emacs expects the following:

File "/home/palomer/temp/test.ml", line 2-4, characters 1-8:
...

Additional information

an easy fix would be to change the "print" function in "parsing/location.ml" to the following:

let print ppf loc =
let ls = loc.loc_start in
let le = loc.loc_end in
let lines =
if ls.Lexing.pos_lnum = le.Lexing.pos_lnum then
sprintf "line %d" ls.Lexing.pos_lnum
else
sprintf "lines %d-%d" ls.Lexing.pos_lnum le.Lexing.pos_lnum
in
fprintf ppf "File "%s", %s, characters %d-%d:\n" ls.Lexing.pos_fname
lines (ls.Lexing.pos_cnum - ls.Lexing.pos_bol)
(le.Lexing.pos_cnum - le.Lexing.pos_bol)

And the "to_string" function in "camlp4/Camlp4/Struct/Loc.ml" might also have to be similarly changed

@vicuna
Copy link
Author

vicuna commented Jun 1, 2011

Comment author: @damiendoligez

Now that emacs supports character positions in error messages, I guess we should change our format, but we will also need to change the corresponding regexp in caml.el.

In the meantime, you should consider using caml-mode in your emacs.

@vicuna
Copy link
Author

vicuna commented Aug 8, 2012

Comment author: @damiendoligez

First step toward fixing this: I have defined a new format for the error messages:

File "foo", line 1, char 2 to line 3, char 4:
blah

Where "4" is the char number within line 3 (not a char offset from line 1).
I have added to caml.el the corresponding regexp, in addition to the old one. (r 12840 and 12843 in trunk)

OCaml still outputs the old format for the moment.

@vicuna
Copy link
Author

vicuna commented Feb 6, 2015

Comment author: @damiendoligez

Note: if we want to use Emacs' default parser, the easiest format would be:

file.ml:12.34-56.78

for "file.ml, line 12, char 34 to line 56, char 78"

Do we want to use this format, or do we think it's too unnatural for non-emacs users?

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

It seems fairly unnatural to me.

@vicuna
Copy link
Author

vicuna commented Dec 9, 2016

Comment author: @dbuenzli

It's the gnu convention https://www.gnu.org/prep/standards/standards.html#Errors it has also the advantage of being a bit more compact.

@dbuenzli
Copy link
Contributor

dbuenzli commented Mar 25, 2019

Nowadays the example reports

File "test.ml", line 2, characters 0-13:
Error: This expression has type string but an expression was expected of type
         int

and emacs' compile-mode highlights the start from the buffer until the end of the "foo" string. I'd say this can be closed (the error location may not be the best but it is supported by emacs see here).

@pmetzger
Copy link
Member

See also discussion in #8541

(I'm not suggesting this not be closed, just linking the other issue in case someone browses this later.)

@Chris00
Copy link
Member

Chris00 commented Apr 13, 2019

FYI, the next release of Tuareg will support the errors (and Warning detection) of OCaml 4.08. Thanks to @Khady for his help on this.

@damiendoligez
Copy link
Member

This particular problem is indeed fixed by #8541.

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

No branches or pull requests

5 participants