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

Emacs doesn't recognize the backtrace error location format #5044

Closed
vicuna opened this issue May 4, 2010 · 4 comments
Closed

Emacs doesn't recognize the backtrace error location format #5044

vicuna opened this issue May 4, 2010 · 4 comments

Comments

@vicuna
Copy link

vicuna commented May 4, 2010

Original bug ID: 5044
Reporter: bluestorm
Status: acknowledged (set by @damiendoligez on 2011-06-01T20:52:21Z)
Resolution: open
Priority: normal
Severity: feature
Category: emacs mode
Related to: #4628 #5070
Monitored by: @gasche

Bug description

Backtrace error locations are not printed in the standard format recognized by emacs. The backtrace format is the following :

Raised at file "gUnify.ml", line 191, characters 24-64
Called from file "list.ml", line 69, characters 12-15
...

The compiler usually produces an error message formatted like this :

File "gUnify.ml", line 147, characters 2-9:
...

@vicuna
Copy link
Author

vicuna commented May 4, 2010

Comment author: @dbuenzli

Which version are you using ?

This should be fixed in 3.11 see #4628

Daniel

@vicuna
Copy link
Author

vicuna commented May 5, 2010

Comment author: bluestorm

You are right, it is fixed under 3.11. Thanks for your patch, and sorry for not searching mantis before reporting.

It's strange that we can't access the character positions of the error message. I don't understand the precise use of the error regexps internal to the Caml mode, but I had a look at emacs compilation-error-regexp-alist documentation, and I came with the following fix, wich works fine in my .emacs :

  (defun caml-change-error-alist-for-backtraces ()
    "Hook to change the compilation-error-regexp-alist variable, to
     search the ocaml backtraces for error locations"
    (interactive)
    (progn
      (setq compilation-error-regexp-alist-alist
            (append  
             '((caml-backtrace
  "^ *\\(?:Raised at\\|Called from\\) file \\(\"?\\)\\([^,\" \n\t<>]+\\)\\1,\
   lines? \\([0-9]+\\)-?\\([0-9]+\\)?\\(?:$\\|,\
  \\(?: characters? \\([0-9]+\\)-?\\([0-9]+\\)?:?\\)?\\)"
                2 (3 . 4) (5 . 6)))
             compilation-error-regexp-alist-alist))
      (setq compilation-error-regexp-alist
            (append compilation-error-regexp-alist '(caml-backtrace)))))
  
  (add-hook 'caml-mode-hook 'caml-change-error-alist-for-backtraces)

(The regexp is mainly an adaptation of the 'caml' regexp preset in emacs compile.el)

I also have the following, to spot error positions in assert failures (Assert_failure("test.ml", 1, 11)) :

  (defun caml-change-error-alist-for-assert-failure ()
    "Hook to change the compilation-error-regexp-alist variable, to
     search the assert failure messages for error locations"
    (interactive)
    (progn
      (setq compilation-error-regexp-alist-alist
            (append  
             '((caml-assert-failure
                "Assert_failure(\"\\([^,\" \n\t<>]+\\)\", \\([0-9]+\\), \\([0-9]+\\))"
                1 2 3))
             compilation-error-regexp-alist-alist))
      (setq compilation-error-regexp-alist
            (append compilation-error-regexp-alist '(caml-assert-failure)))))
   
  (add-hook 'caml-mode-hook 'caml-change-error-alist-for-assert-failure)

Would it be possible to integrate something similar in caml.el ?

@vicuna
Copy link
Author

vicuna commented Jul 10, 2013

Comment author: @damiendoligez

In 4.01.0+dev, the backtrace works fine, including the character positions.

I'm turning this into a feature wish to make it work also for assert failures.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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

1 participant