Setting RUSTFLAGS="-Awarnings" manually every time you run cargo is annoying and repetitive. Could we have a flag such as --errors when running cargo to make it easier to display errors as sometimes warnings make it hard to find.
2 Likes
There is an unstable config for it, but it doesn't appear to have a command line parameter.
1 Like
I don't think that this is the right approach to this problem. I fully agree that there is a problem though. It can be really hard to see errors hidden within lots of different warnings that are usually not relevant when developing. We don't need config or options to handle this better, we need better defaults.
I think it would be nice if we had a way to make the errors more visible than the warnings. Maybe something like re-printing errors at the end of the build log if there were several warnings?
2 Likes
Errors themselves can be just as problematic as warnings — e.g. some erroneous code can break trait solving for the rest of the program, resulting in a flood of errors around Sized or other ubiquitously used traits. I would say the most valuable UX change would be to reprint or otherwise draw attention to the very first error, which is the one most likely to be accurate and relevant.
5 Likes
Only a workaround really, but what I find most useful when developing is to have a terminal open with the following running :
cargo watch --clear -x check -x build -x test -x clippy -x doc
--clear will clear the output when recompiling, so if there are errors I can go at the top and see the first error. Then when nothing errors, I see tests failing, then when tests pass I see clippy errors, etc.
1 Like
I use bacon for the same purpose, but this is an especially important UX issue for new users who probably have not learned about (or may not wish to explore) third-party tools, and won’t have learned that looking at the top is valuable.
3 Likes
some erroneous code can break trait solving for the rest of the program, resulting in a flood of errors around Sized or other ubiquitously used traits
Every time this happens it's unambiguously a bug in the compiler and you should open issues for it :). But also sometimes it can be really hard to fix.
1 Like
But is it in general a compiler bug every time the compiler recovers from an error in an incorrect (according to the user's intent) fashion? I presume not, and every time that happens, looking at the first error first is useful advice.
build.warnings = "allow|deny" is not meant to significantly innovate on the workflow. Unsure if build.warnings = "allow" is motivating on its own but build.warnings = "deny" is and supporting both is a natural way of expressing this in the config.
1 Like
imo it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.
1 Like
Tangentially: does the same logic apply to parser recovery? I occasionally see "mismatched braces" error pointing very far from the actually mismatched brace.
RUSTFLAGS (like most env variables) is a terrible interface for anything that you don't set once in your login script and then forget about it. Sometimes it can be useful to set it once in your current session, but because it's entirely hidden state you're going to forget it and then be confused why, for example, one of your terminal windows gives different output than the one next to it. Anything you might want to ever change more often than that should be a command-line parameter and a per-profile setting in Cargo.toml so you can have separate "devloop" and "now I care about warnings" profiles. Cargo is well known for having some idiosyncratic opinions as to what goes to Cargo.toml, what goes to .cargo/config.toml, what can be set on the command line, and what requires the use of RUSTFLAGS, that don't quite match many valid workflows that people have (I know there are efforts to alleviate some of these mismatches).
3 Likes
Using "context" commands can help with this.
alias rust-no-warnings="env RUSTFLAGS=-Awarnings"
Then you can do rust-no-warnings cargo for a one-off build or rust-no-warnings bash for a "session" of it being active.
Ideally it would amend RUSTFLAGS, in which case a simple shell script in ~/.local/bin would be better.
Yes. It should either recover in a way that captured user intent, or in a way that silences subsequent errors (potentially hiding subsequent desired errors). Any other behavior is unintended.
Tangentially: does the same logic apply to parser recovery? I occasionally see "mismatched braces" error pointing very far from the actually mismatched brace.
Yes. If you have repro cases we can try to figure out how to account for those cases better. The problem is that by the time the parser is doing its things the Token Tree was already constructed. The error happens at the point the mismatch was detected, not where it happened. The parser keeps track of opened but unclosed delimiters to point at, but that logic might be incomplete, if you're seeing cases where we don't point at the right place already.
Well then, one followup error that recently annoyed me came to mind, so I tried writing a fix for it:
2 Likes