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 report cites line-number which is not anywhere close to the actual error. (Mantis 7063) #102

Closed
damiendoligez opened this Issue Feb 8, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@damiendoligez
Member

damiendoligez commented Feb 8, 2016

This is http://caml.inria.fr/mantis/view.php?id=7063 :

In some cases camlp4 reports very odd line-numbers when there is an error.

When I compile the attached file:

ocamlfind c -g -c -syntax camlp4o -package mikmatch_str main.ml

I get the following error:

File "main.ml", line 8, characters 7-8:
Parse error: [regexp] expected after "=" (in [str_item])
File "main.ml", line 1:
Error: Error while running external preprocessor
Command line: camlp4 '-I' '/home/me/.opam/4.02.3/lib/ocaml/camlp4' '-I' '/home/me/.opam/4.02.3/lib/ocaml' '-I' '/home/me/.opam/4.02.3/lib/ocaml' '-I' '/home/me/.opam/4.02.3/lib/mikmatch_str' '-parser' 'o' '-parser' 'op' '-printer' 'p' 'str.cma' 'unix.cma' 'pa_mikmatch_str.cma' 'main.ml' > /tmp/ocamlppca2754

There, camlp4 tells me that something is wrong on line 8, column 7
which is very far from the actual error (line 30, column 54).

In this case, it seems that the reported line number with the error
and the line with the actual error can be arbitrarily far.

This can be a source of frustration for programmers.

The attached file is very artificial, but I stumbled upon this with a real program I am working on.

type r1 = {l1a : r4; l1b : r2}
and  r2 = {l2a : string; l2b : r3}
and  r3 = {l3a : string; l3b : string}
and  r4 = {l4a : string; l4b : string}
and  r5 = {l5a : r1; l5bbbb : r1}
and  r6 = {l6a : r5; l6cc : r5}

RE foo = 'bar'

let _ = let foo = 42 in
        {l6a = {l5a = {l1a = {l4a = "s" ^ "1" ^ "a";
                              l4b = "sab" ^ "1bb" ^ "accc"};
                       l1b = {l2a = "sa" ^ "2" ^ "acc";
                              l2b = {l3a = "saaa" ^ "3bbb" ^ "a";
                                     l3b = "s" ^ "3" ^ "b"}}};
                l5bbbb = {l1a = {l4a = "s" ^ "1" ^ "a";
                                 l4b = "sab" ^ "1bb" ^ "accc"};
                          l1b = {l2a = "sa" ^ "2" ^ "acc";
                                 l2b = {l3a = "saaa" ^ "3bbb" ^ "a";
                                        l3b = "s" ^ "3" ^ "b"}}}};
         l6cc = {l5a = {l1a = {l4a = "s" ^ "1" ^ "a";
                               l4b = "sab" ^ "1bb" ^ "accc"};
                        l1b = {l2a = "sa" ^ "2" ^ "acc";
                               l2b = {l3a = "saaa" ^ "3bbb" ^ "a";
                                      l3b = "s" ^ "3" ^ "b"}}};
                 l5bbbb = {l1a = {l4a = "s" ^ "1" ^ "a";
                                  l4b = "sab" ^ "1bb" ^ "accc"};
                           l1b = {l2a = "sa" ^ "2" ^ "acc";
                                  l2b = {l3a = "saaa" ^ "3bbb" ^ "a";
                                         l3b = "s" ^ ^ "3" ^ "b"}}}}}
@diml

This comment has been minimized.

Show comment
Hide comment
@diml

diml Feb 9, 2016

Member

I think it's because of the TRY in the grammar, I'll try to debug that

Member

diml commented Feb 9, 2016

I think it's because of the TRY in the grammar, I'll try to debug that

diml added a commit that referenced this issue Feb 9, 2016

@diml

This comment has been minimized.

Show comment
Hide comment
@diml

diml Feb 9, 2016

Member

The problem comes from the fact that camlp4 accepts { expr with ... } without parentheses for complicated expr. To parse { something, it tries both the {expr with ...} form and { label = expr; ... } form and then report errors at this level. I tried a hack to always choose the latter form when label = follows {. I'll need to check it doesn't break code in opam

Member

diml commented Feb 9, 2016

The problem comes from the fact that camlp4 accepts { expr with ... } without parentheses for complicated expr. To parse { something, it tries both the {expr with ...} form and { label = expr; ... } form and then report errors at this level. I tried a hack to always choose the latter form when label = follows {. I'll need to check it doesn't break code in opam

@diml diml closed this in 80e25ac Feb 9, 2016

diml added a commit that referenced this issue Feb 15, 2016

diml added a commit that referenced this issue Feb 15, 2016

diml added a commit that referenced this issue Feb 15, 2016

diml added a commit that referenced this issue Mar 1, 2016

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