-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
rustc "file:line-num" output has become incompatible with emacs' default compilation-mode #6887
Comments
Potential fixes:
|
Here's something that might do the job:
(and then add Not sure if this is really the right way to go about modularly extending that list, though. |
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? |
I'm going to close this, since it seems to work. |
@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? |
On Emacs Version 24.2 (9.0), for the following test program, I see the reported problem still: Makefile:
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)))));
}
When I try to follow the hyperlink presented by emacs at the line with Reopening ticket, leaving assigned to self for further investigation. (Perhaps I need to upgrade my emacs on this machine, not sure yet.) |
So this is not a problem uniformly across the board for all of our error message output. |
(I wonder if this is happening because its misinterpreting the colon in the middle of the message, in |
I determined, via bisection of If you paste the following into an Emacs
Namely, if you put the cursor at the end of the expression marked "CASE 1" and hit |
bizarre: This line works: This line does not: (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. |
(It seems like one potential (and simple) fix on the Emacs side would be to change the |
In case anyone has the brainpower to debug the
Meanwhile I am happy taking the improvement here, if it does indeed fix the bug. |
�Argh, it did fix the bug before I revised it in response to a review comment and accidentally added a second |
part of #8793 |
The problem still exist for me when using |
Adding these lines to
https://github.com/fschutt/.emacs/blob/master/.emacs#L1574-L1639 |
Alas, didn't work for me at all. I am using the lastest nightly build. That is to say, it always prompts me for locating the file. |
…tion-lint, r=xFrednet A metadata collection monster This PR introduces a metadata collection lint as discussed in rust-lang#4310. It currently collects: * The lint ID * The lint declaration file and location (for rust-lang#1303) * The lint group * The documentation * The applicability (if resolvable) * If the suggestion is a multi-part-suggestion This data has a slightly different structure than the current [lints.json](https://github.com/rust-lang/rust-clippy/blob/gh-pages/master/lints.json) and doesn't include depreciated lints yet. I plan to adapt the website to the new format and include depreciated lints in a follow-up PR :). The current collected json looks like this: [metadata_collection.json](https://gist.github.com/xFrednet/6b9e2c3f725f476ba88db9563f67e119) The entire implementation is guarded behind the `metadata-collector-lint` feature and the `ENABLE_METADATA_COLLECTION` environment value to prevent default collection. You can test the implementation via: ```sh $ ENABLE_METADATA_COLLECTION=1 cargo test --test dogfood --all-features ``` changelog: none --- The size of this PR sadly also grew into a small monster, sorry! I definitely plan to improve on this! And it's totally okay if you take your time with this :) r? `@phansch` cc: `@flip1995`
Hi helinwang,
I've added these lines to my .emacs and I'm still getting prompted to find the file when middle-clicking on errors. Is this what your changes were trying to fix? I have emacs 26.03 on Ubuntu 20.04. It looks to me like Emacs is having problem with the relative paths. Not sure how to teach it to look for files under the project root (and 'cd && make ...' does not work; yes, we build with make, which calls cargo etc). As far as I understand the original report, it's about Emacs not being able to parse the cargo output, not specifically about finding files. |
Hi @fencekicker yes these lines tell emacs to parse the rust output file correctly, not sure why it does not work for you. I guess somehow the command does not activate for you. |
@helinwang what version of emacs are you using? At least in my case, I see the error messages refer to relative paths: Compiling foobar v0.1.0 (/<full/path/to/foobar>) When I click the mouse on the file, Emacs opens a different folder. I can see the file names highlighted properly, it's just that clicking on them opens a file picker. Is that the issue you were seeing before the changes to init.el? |
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:
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.)
The text was updated successfully, but these errors were encountered: