rustc "file:line-num" output has become incompatible with emacs' default compilation-mode

[pnkfelix]

The output from rustc used to be compatible with emacs compilation-mode's regexp, so that I could immediately visit the point of error via generated links in a compile-mode buffer.

But now it products output where, at least on my emacs install, the compilation mode gets confused.

As a concrete example, it interprets this output:

llist2.rs:9:0: 12:1 error: not all control paths return a value
llist2.rs:9 fn place_top(pile: Option<~card>, newcard: ~card) -> ~card
llist2.rs:10 {
llist2.rs:11 
llist2.rs:12 }

where it sees the first line as the place to find the link to the error (and the subsequent lines are not linked), but when I click, it thinks the error is in a file named 9:0 at line 12, column 1.

(I can probably figure this out sometime in the next week, so I am going to assign this to myself; I just wanted to file it away now.)

[pnkfelix]

Potential fixes:

• massage rustc's output
• an alternative would be to change rust-mode.el to extend the compilation-error-regexp-alist
• or to change rust-mode.el to add an entry for 'rust to compilation-error-regexp-alist-alist

[pnkfelix]

Here's something that might do the job:

(setq compilation-error-regexp-alist-alist
      (cons '(rustc "^\\([^ \n]+\\):\\([0-9]+\\):\\([0-9]+\\): \\([0-9]+\\):\\([0-9]+\\) \\(?:[Ee]rror\\|\\([Ww]arning\\)\\):" 1 (2 . 4) (3 . 5) (6))
        compilation-error-regexp-alist-alist))

(and then add 'rust to compilation-error-regexp-alist.

Not sure if this is really the right way to go about modularly extending that list, though.

[msullivan]

So, using "M-x compile", and building, I seem to be able to jump to errors just fine. Are you talking about something different, or has it gotten fixed?

[msullivan]

I'm going to close this, since it seems to work.

[pnkfelix]

@msullivan okay. Just to fill me in for when I look at this again, what version of Emacs (host OS and version number) were you using?

[pnkfelix]

On Emacs Version 24.2 (9.0), for the following test program, I see the reported problem still:

Makefile:

run-ne: nonexhaust.bin
    ./$<

%.bin: %.rs
    rustc -o $@ $<

nonexhaust.rs:

fn foo(x: Option<Option<int>>) -> int {
    match x {
        Some(Some(n)) => n,
        Some(None) => 3
    }
}

fn main() {
    println(fmt!("%d", foo(Some(Some(4)))));
}

*compilation* output:

-*- mode: compilation; default-directory: "/tmp/show-el-fail/" -*-
Compilation started at Sat Aug 10 13:35:58

make
rustc -o nonexhaust.bin nonexhaust.rs
nonexhaust.rs:2:4: 5:5 error: non-exhaustive patterns: None not covered
nonexhaust.rs:2     match x {
nonexhaust.rs:3         Some(Some(n)) => n,
nonexhaust.rs:4         Some(None) => 3
nonexhaust.rs:5     }
error: aborting due to previous error
make: *** [nonexhaust.bin] Error 101

Compilation exited abnormally with code 2 at Sat Aug 10 13:35:59

When I try to follow the hyperlink presented by emacs at the line with 2:4: 5:5 error, it prompts me with:
Find this error in (default 2:4): /tmp/show-el-fail/ (where /tmp/show-el-fail is the current working directory).

Reopening ticket, leaving assigned to self for further investigation. (Perhaps I need to upgrade my emacs on this machine, not sure yet.)

[pnkfelix]

1. Upgraded to Emacs 24.3. (It supports Mac OS X full screen mode, woo). But the problem of this ticket continues to arise there.
2. If I inject a new different error earlier in that same file, the compilation mode correctly extracts the file name:

-*- mode: compilation; default-directory: "/tmp/show-el-fail/" -*-
Compilation started at Sat Aug 10 13:52:17

make
rustc -o nonexhaust.bin nonexhaust.rs
nonexhaust.rs:2:10: 2:17 error: expected `;` or `}` after expression but found `problem`
nonexhaust.rs:2     other problem here
                          ^~~~~~~
make: *** [nonexhaust.bin] Error 101

Compilation exited abnormally with code 2 at Sat Aug 10 13:52:17

So this is not a problem uniformly across the board for all of our error message output.

[pnkfelix]

(I wonder if this is happening because its misinterpreting the colon in the middle of the message, in non-exhaustive patterns: None, and incorrectly backtracking to match 2:4 as the file name.)

[pnkfelix]

I determined, via bisection of compilation-error-regexp-alist, that we are probably relying on the gnu compilation error regexp.

If you paste the following into an Emacs *scratch* buffer, you can interactively see how the regexp is getting confused in some way by the different outputs:

(re-search-forward
 (cadr (assq 'gnu compilation-error-regexp-alist-alist)))   ;; CASE 1

nonexhaust.rs:2:4: 4:5 error: non-exhaustive patterns: None not covered

(re-search-forward
 (cadr (assq 'gnu compilation-error-regexp-alist-alist)))   ;; CASE 2

nonexhaust.rs:2:10: 2:15 error: expected `;` or `}` after expression but found `stuff`

Namely, if you put the cursor at the end of the expression marked "CASE 1" and hit C-x C-e, the cursor will jump to the point between 4:5 and error:. If you do the same for "CASE 2", the cursor jumps between 2:10 and 2:15. (The latter is what we want, in terms of Emacs then extracting the correct substrings for filenames and line numbers.

[pnkfelix]

bizarre:

This line works: nonexhaust.rs:2:10: 2:5 error: message

This line does not: nonexhaust.rs:2:10: 2:15 error: message

(That's assuming my earlier analysis of what "correct" and "incorrect" behavior are when experimenting in the scratch buffer.)

Surely the number of digits in the column specification should not cause the regexp matching behavior to change so radically? This is looking more and more to me like an Emacs deficiency, not a Rust one.

[pnkfelix]

(It seems like one potential (and simple) fix on the Emacs side would be to change the 'gnu regexp to filter out not just "filenames" composed solely of digits, but also "filenames" composed solely of digits and colon characters. I might submit that over there. But it would be good for us to have a fix in rust-mode.el in the meantime on our end.)