autocfg
autocfg copied to clipboard
Hide rustc output by default.
But add an environment variable to allow showing it, if wanted.
Fixes #30
Having now had to undo the hiding in Firefox to find out where a specific problem was coming from, it would be better if autocfg were able to print the output when something unexpected happens, but hide it when the normal behavior of the test happens (even if that means it's an error).
Example of an expected error:
[crossbeam-utils 0.8.1] error[E0412]: cannot find type `AtomicU128` in module `core::sync::atomic`
[crossbeam-utils 0.8.1] --> <anon>:1:38
[crossbeam-utils 0.8.1] |
[crossbeam-utils 0.8.1] 1 | pub type Probe = core::sync::atomic::AtomicU128;
[crossbeam-utils 0.8.1] | ^^^^^^^^^^ help: a struct with a similar name exists: `AtomicU16`
[crossbeam-utils 0.8.1]
[crossbeam-utils 0.8.1] error: aborting due to previous error
Example of an unexpected error:
[crossbeam-utils 0.8.1] error: Profile-guided optimization does not yet work in conjunction with `-Cpanic=unwind` on Windows when targeting MSVC. See issue #61002 <https://github.com/rust-lang/rust/issues/61002> for more information.
[crossbeam-utils 0.8.1]
[crossbeam-utils 0.8.1] error: aborting due to previous error
I don't know if rustc returns different error codes in those cases.
I don't know if rustc returns different error codes in those cases.
It does not -- I get exit code 1
for regular errors and for that PGO error.
Which leaves us in a tough place -- I don't want to get in the business of parsing errors and trying to decide what's important.
I gather you have applied this patch (or something like it) to your Firefox builds. How has that worked out in practice? Any more instances like @glandium's where you would have wanted the output after all?
We've applied this patch: https://phabricator.services.mozilla.com/D101861#change-iVkOTcyFYu4x
We haven't hit other instances where the output would have been useful, but it's typically in those rare instances where it's needed that you don't necessarily think of such hidden output to be containing the gems you're looking for.
One possible heuristic would be to check for the name of what's looked for in the output, and if it's not there, print out the output.
FWIW I was quite happy about this output when debugging autocfg issues recently.