Add rustc --fatal which stops at the first build error
#27189
Comments
|
Maybe this should be the default - fixing a single error and recompiling is probably the most common workflow. If errors are fatal (and this was default) it will exacerbate the frustration of not knowing how much progress you are making as you work through the errors. To disambiguate, this could continue counting errors without displaying them and terminate with '... and at least {} other errors, run with ... to display them'. |
|
In the meantime, one can use (Of course that's a debugging option, i.e. inherently unstable, so we should still leave this ticket open.) |
|
@brson there is also the potential problem that the actual error in the code that really needs to be fixed is not the first error that is signaled, but rather is flagged by some later error message that is emitted. (Having said that, I'm not sure how often I encounter the latter scenario. I would need to gather statistics.) |
|
I would personally not want this to be the default, I prefer to have as many errors as possible listed for me to fix. Sometimes I pipe the compiler into I think clang has an option for the maximum number of errors to be printed before it stops, and that seems like an option we'd want to have regardless anyway. |
|
I agree this shouldn’t be the default. I’d only want this when there’s a really large number of errors. Unfortunately piping into |
|
I don't think error cascades are a significant problem with rustc - mostly "the type of this value must be known" and bogus regionck errors. I don't think there's a better way of limiting the number of error lines than |
|
Note that our diagnostics infrastructure is not particularly adaptable for this request. Consider a diagnostic which currently returns an error and associated help/hint message. Since these are printed via two different calls without any future hints, a naive implementation of |
|
Bump. I'd like this to be fixed aswell. Also I think this behaviour should be default unless |
|
Another 👍 from me. Possibly we might want a --limit-errors=3 or something (if we don't already). |
|
I'd like to have a timeout after the first error. I.e, provide all errors that are available within a certain number of milliseconds after the first error. We're interested in speed, right? Limiting the number of errors displayed is orthogonal. For example, The upside is that this should be pretty easy to implement - perhaps even possible as a wrapper executable. |
For me it's about not wanting to scroll up my terminal to find the top of the errors. Just giving the first few is enough, especially since fixing those is often enough to fix all the other errors. |
|
This could also be helpful for those of us building projects in the background in our editors to show errors. neomake/neomake#801 (comment) is a rather crude workaround (using the |
|
I also think that when refactoring it's very annoying to have hundreds of errors, however I'd more like something like a "stop after x errors" because a single error would slow down development (you had to compile pretty often). If it should be default, I'd probably stop after 10 errors because more than 10 are most likely not useful. |
|
Does something like this exist now? I'm refactoring some code and it would be great to just see one or two errors at a time. The large amount of compiler errors is a bit much to deal with. |
|
@sunjay On Linux or OS X you can use something like: |
|
I'm using I would prefer cargo did what git does - automatically open a pager if the errors exceed the height of the window. Beginner rust development is usually either no errors or 30+ errors that share a single root cause. |
|
FWIW, the reason I don’t use a page is that it has to be exited manually. I also use an inotify-based script (similar to "cargo watch") to recompile automatically when a source file changes, so I only have to save from my editor to start a new compilation, no need to switch focus to the terminal. I imagine the inotify thing could be a background task that would kill the pager when it’s time to recompile, but that seems more tricky and fragile. |
|
At least on macOS (zsh) I do lose the color with I also tried the zsh exclusive I really hope we'll get a |
|
Well, while working on lifetimed handles, I killed the build process after 10 minutes of printing errors. |
|
A workaround, which takes advantage of the fact that most processes are killed by SIGPIPE is: |
|
Woot! also works with cargo watch! |
|
The other ticket is also closed as duplicated. Wonder is it that complicated to implement that option. |
|
I played around with trying to implement this yesterday, with no success. I don't really understand how the diagnostics system is structured though, so somebody with more experience with it will probably have more luck. I did, however, write an awk script that does pretty much the same thing: cargo watch -x "build --color=always 2>&1 | awk '/error.*:/{n++};n < 2'"Replace |
|
That workaround is still true today: all it does is just call
fn bump_err_count(&self) {
self.err_count.fetch_add(1, SeqCst);
self.panic_if_treat_err_as_bug();
}
fn panic_if_treat_err_as_bug(&self) {
if self.treat_err_as_bug() {
let s = match (self.err_count(), self.flags.treat_err_as_bug.unwrap_or(0)) {
(0, _) => return,
(1, 1) => "aborting due to `-Z treat-err-as-bug=1`".to_string(),
(1, _) => return,
(count, as_bug) => {
format!(
"aborting after {} errors due to `-Z treat-err-as-bug={}`",
count,
as_bug,
)
}
};
panic!(s);
}
}
cargo rustc --color=always -v --no-default-features -- -Z treat-err-as-bug=1 -v |
|
Ok, I found (at least) one case where For this case: [package]
name = "bad_Z"
version = "0.1.0"
authors = ["howaboutsynergy <howaboutsynergy@pm.me>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
[features]
bad = [] fn main() {
println!(
"Hello, world! {}",
#[cfg(not(feature = "bad"))]
"arg when not bad",
#[cfg(feature = "bad")]
"arg when bad",
);
}Compiler output when Normal compiler output: |
|
so annoying to have hundreds of errors go for no reason, each time scroll down/up, wait few minutes on the compilation. I understand there are some ugly workarounds on Linux, but on Windows? It's so straight forward not to compile after few - so upset 👎 😭 |
|
Here's a workaround: the default limit is 1, error messages come first. Tested on GNU/Linux, probably works on Windows and macOS as well. |
|
Incremental improvement on the pipelines posted above: |
|
Fwiw: It would be nice if |
|
Maybe a compromise would be to order the errors in reverse, so the people who fix one error at a time dont have to scroll so much. Coming from other languages, I notice the constant scrolling really slows down my work flow |
|
That seems like a hack but I'll take anything at this point 😅 |
error: expected `;`, found `RedditSearch`
--> src/main.rs:24:22
|
24 | let state = State{}
| ^ help: add `;` here
25 |
26 | RedditSearch{}.start();
| ------------ unexpected token
error: expected `;`
--> src/main.rs:26:3
|
26 | RedditSearch{}.start();
| ^^^^^^^^^^^^
error[E0601]: `main` function not found in crate `webmentioner`
--> src/main.rs:1:1
|
1 | / pub use actix::Actor as _;
2 | |
3 | | mod reddit; pub use reddit::*;
4 | |
... |
39 | | system.await
40 | | }
| |_^ consider adding a `main` function to `src/main.rs`
An example of a useless second error, I do have a main function, but because I forgot a semicolon rustc flips out. Now I need to read the error and realize it isn't an error before finding the actual issue. It would be so much easier if an actionable error was at the bottom of my terminal. This is legitimately my biggest complaint about rust. Very often the later errors are not problems at all, or are at least made more clear by fixing the earlier errors. I understand that some people like batch fixing errors but I definitely prefer the iterative style. This feature would help me stay focused on the errors that matter, instead of having to scroll around constantly. |
|
I spent a bunch of time today trying to figure out why a struct was missing from a library when docs.rs says that it exists. I checked the docs, double checked the version and if any features were required. Then I realized that it was just Rust making stuff up about a dependency that I forgot to install because apparently more errors is more helpful. error[E0433]: failed to resolve: use of undeclared crate or module `password_hash`
--> src/crypto.rs:123:13
|
123 | let salt = password_hash::SaltString::generate(&mut rand_core::OsRng);
| ^^^^^^^^^^^^^ use of undeclared crate or module `password_hash`
error[E0433]: failed to resolve: use of undeclared crate or module `password_hash`
--> src/crypto.rs:124:20
|
124 | Ok(password_hash::PasswordHasher
| ^^^^^^^^^^^^^^ not found in `password_hash`
|
help: consider importing this trait
|
3 | use argon2::PasswordHasher;
|
error[E0433]: failed to resolve: use of undeclared crate or module `password_hash`
--> src/crypto.rs:137:20
|
137 | Ok(password_hash::PasswordHash::new(&hash)?
| ^^^^^^^^^^^^ not found in `password_hash`
|
help: consider importing this struct
|
3 | use argon2::PasswordHash;
|
|
|
There is |
|
For what it’s worth tooling has changed a lot since I filed this in 2015. These days I use VSCode with rust-analyzer, the dedicated error pane fixes all the pain points described here for me (and allows quickly navigating an editor to relevant code). Since nothing concrete happened from this issue in all these years, I’m gonna make a judgment call and close it. I suspect some folks would still like something to be added here, if someone wants to champion it I recommend pushing a proposal through the compiler team’s process: https://forge.rust-lang.org/compiler/new_option.html |
|
I appreciate that you may no longer be interested but there are still other users who are. Could you please reopen this so that we can continue to track progress (or lack there of) in the same place? If you are no longer interested in receiving notifications you can unsubscribe from this issue using the button on the issue page or the link in the email. While many users are using IDE error messages lots of us still use a separate compiler for one reason or another (personally it makes my edit and run loop much easier as all of my output is in the same place). So for now this seems like a relatively easy mitigation to the problem of the tons of false-positive errors that are generated by the compiler. (I'm not holding my breath for the root cause to be fixed). So I think it makes sense to leave this open as a specific feature request with direct benefits to the productivity of many Rust users. |
|
Please don't close this! There are many of us still desperate for this feature, even if you've personally lost interest. Feel free to unsubscribe from notifications after you reopen it if you're no longer interested. |
That’s the thing: there won’t be any progress until someone care enough to make it happen. So far nobody has cared enough in 8 years. If and when they do, this issue won’t serve a purpose anyway since the compiler team’s (relatively) new process involves a Major Change Proposal filed in another repo. By the way the MCP should be more concrete than what we have here: is it a new CLI option for rustc? Also Cargo? What does it do exactly? Isn’t an auto-pager like git a better idea? Etc. Does "desperate" mean willing to do the work? |
Alternative is probably much harder to implement: just have smarter compiler messages by default, no additional CLI options are needed. There are some cases when it might makes sense to see both errors and warnings in the same compiler output, but in many cases such warnings are just useless consequences of the errors, which steal our attention a lot. Is there any way to detect useless messages and ignore them? For other insights and for anyone who suffer from this issue — please check out these few ideas in this dirty limited workaround I mentioned before. Thanks.
For me specifically it means the following: please notice the issue and workaround for it, which exists there with a hope to give compiler team and anyone concerned some inspiration on how it can be fixed in the compiler/cargo; and yes far few of us can invest time in going through all the bureaucratic procedure of introducing MCP/RFC/etc. and all this, life is too short, but it doesn't mean this issue is not important and should be just ignored. |
can i just check i'm understanding correctly? the compiler team has invented a process (which nobody who doesn't actively develop Rust will know anything about), and which involves ignoring issues and feature requests filed by end-users against the official project repo? and that's on… the end-users? okay cool. |
|
Nothing in "on" end users. Things happen when a contributor wants to push a particular thing forward. I close this issue as the end user who initially filed it, because I no longer think it’s a good idea. |
|
I appreciate that you no longer think that it is a good idea but apparently there are 80 other people who still think it is. So closing the discussion for everyone is not very polite and makes the discussion history difficult to follow if someone needs to open a separate issue. |
|
so ugly it's not an option after all these years - so inconvenient 😞 |
(Should this be an RFC?)
Motivation
When refactoring, one may have dozens or hundreds of build errors which need to be fixed one by one. Sometimes, a build error is only a consequence of an earlier error rather than something that need to be fixed itself:
In such cases, it is a better strategy to start by looking at and fixing earlier errors (in the compiler output) first. The second error might just go away when the first is fixed.
In a large enough crate, it’s easy to get well over one screenful of compiler output. So the workflow is something like:
Proposal
Add a command-line argument to rustc, called something like
--fatal. When it is given and the compile finds a build error (the kind that would cause the compilation to fail eventually, so not warnings), exit immediately after printing diagnostics for this error. This is the opposite of the usual strategy of finding as many errors as possible at once.The new workflow is:
(With some inotify-based tricks, it’s not even necessary to switch focus from the terminal.)
The text was updated successfully, but these errors were encountered: