Stop prepending the path and line number to every line in error messages

[bstrie]

For the sake of people with 80-character terminals, Rust code is limited to 78 characters in width. So why do error messages on 80-character terminals look like this:

/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs:24:0: 29:1 wa
rning: type, variant, or trait must be camel case
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs:24 trait file
search {
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs:25     fn sys
root() -> Path;
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs:26     fn lib
_search_paths() -> ~[Path];
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs:27     fn get
_target_lib_path() -> Path;
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs:28     fn get
_target_lib_file_path(file: &Path) -> Path;
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs:29 }

This is a pathological case, but I still manage to hit this frequently even though my term is often well wider than 80 characters.

Here's how Java formats its error messages:

jello.java:3: cannot find symbol
symbol  : variable Exception
location: class jello
        throw Exception;
              ^
1 error

Taking inspiration from this, Rust error messages could instead look like:

Warning: type, variant, or trait must be camel case
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs 24:0-29:1
trait filesearch {
    fn sysroot() -> Path;
    fn lib_search_paths() -> ~[Path];
    fn get_target_lib_path() -> Path;
    fn get_target_lib_file_path(file: &Path) -> Path;
}

[brson]

We could also print the relative path instead of absolute. Whatever the solution it needs to be compatible with emacs's compilation buffers.

[nikomatsakis]

Brian Anderson wrote:

We could also print the relative path instead of absolute. Whatever
the solution in needs to be compatible with emacs's compilation buffers.

I wanted to say the same thing. The current situation is nice (for me)
because emacs never has trouble resolving the filename (not always the
case for other compilers!)

[bstrie]

Does compatibility with emacs' compilation buffers require prepending paths and line numbers to each line?

[brson]

Emacs supports a variety of error reporting formats, so I imagine we have some flexibility. Finding out exactly what it accepts may require reading the code.

We will need to make sure it's ok with vim users to.

[brson]

I think the answer is no though. If emacs decides a line is an error message it will try to interpret it, otherwise it will just print it. Some lines must be crafted to look special to emacs, other lines must be careful to not look special.

[Dretch]

Building on @bstrie's example, I think it would be even better if it was made explicit which type, variant of trait is being referred to, like:

Warning: type, variant, or trait must be camel case
/home/ben/code/rust-projects/rust/src/rustc/metadata/filesearch.rs 24:7-24:17
23:
24: trait filesearch {
          ^
25:    fn sysroot() -> Path;
26:    fn lib_search_paths() -> ~[Path];

(I also changed the span in question to just cover the trait name, rather than the whole trait block).

[bstrie]

@Dretch I believe that's been noted in #3522.

[catamorphism]

Bumping to 0.7

[catamorphism]

Not critical for 0.7, de-milestoning.

[emberian]

Nominating for production ready.

B-Clarifying to work out the exact output desired.

[pnkfelix]

not accepted for production ready

[huonw]

Traige: still a problem. My preference is for relative paths in the error/warnings/notes and no paths/spans on the code itself. Some examples of other compilers (all invoked <foo> 3533.<ext>):

Haskell

main = putStrLn 1

GHC

[1 of 1] Compiling Main             ( 3533.hs, 3533.o )

3533.hs:1:17:
    No instance for (Num String) arising from the literal `1'
    Possible fix: add an instance declaration for (Num String)
    In the first argument of `putStrLn', namely `1'
    In the expression: putStrLn 1
    In an equation for `main': main = putStrLn 1

Works with M-x compile.

Hugs

runhugs: Error occurred
ERROR "3533.hs":1 - Unresolved top-level overloading
*** Binding             : main
*** Outstanding context : Num [Char]

Doesn't work.

C

int main() { main + main; }

GCC

3533.c: In function ‘main’:
3533.c:1:19: error: invalid operands to binary + (have ‘int (*)()’ and ‘int (*)()’)
 int main() { main + main; }
                   ^

Works.

Clang

3533.c:1:19: error: invalid operands to binary expression ('int (*)()' and 'int (*)()')
int main() { main + main; }
             ~~~~ ^ ~~~~
1 error generated.

Works.

D

module main;
void main() { return 1; }

LDC2

3533.d(2): Error: long has no effect in expression (1)
3533.d(2): Error: cannot return non-void from void function

Doesn't work.

GDC

3533.d:2: Error: long has no effect in expression (1)
3533.d:2: Error: cannot return non-void from void function

Mostly works (the Error: seems to get interpreted as the column, but the jump-to-error functionality still works).

Go

package main
func main() { "foo" + 1 }

play.golang.org

prog.go:2: cannot convert "foo" to type int
prog.go:2: invalid operation: "foo" + 1 (mismatched types string and int)

(My package manager isn't letting me install straight golang atm.)

GCCGO

3533.go:2:21: error: value computed is not used
 func main() { "foo" + 1 }
                     ^

Works.

[pnkfelix]

Does compatibility with emacs' compilation buffers require prepending paths and line numbers to each line?

The answer to this question was indeed "no." (I've become much more intimate with compilation mode since tackling #6887.)