autocfg icon indicating copy to clipboard operation
autocfg copied to clipboard

Is there some way to hide the rustc output?

Open nical opened this issue 3 years ago • 6 comments

Hi,

Firefox's build and CI tooling parses the logs including verbose build script output to find and highlight errors. It helps a lot with quickly figuring out where build problems are, gets false positives from autocfg as it sees the rustc errors generated by attempts at determining if configurations build.

For example this:

 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u8
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u8
 INFO -  [crossbeam-epoch 0.8.0] cargo:rustc-cfg=has_min_const_fn
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u16
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u16
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u32
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u32
 INFO -       Running `/builds/worker/workspace/obj-build/release/build/crossbeam-utils-aca7e78e5e03b092/build-script-build`
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u64
 INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u64
ERROR -  [crossbeam-utils 0.8.1] error[E0412]: cannot find type `AtomicU128` in module `core::sync::atomic`
 INFO -  [crossbeam-utils 0.8.1]     --> <anon>:1:38
 INFO -  [crossbeam-utils 0.8.1]      |
 INFO -  [crossbeam-utils 0.8.1] 1    |   pub type Probe = core::sync::atomic::AtomicU128;
 INFO -  [crossbeam-utils 0.8.1]      |                                        ^^^^^^^^^^ help: a struct with a similar name exists: `AtomicU16`
 INFO -  [crossbeam-utils 0.8.1]      |
 INFO -  [crossbeam-utils 0.8.1]     ::: /builds/worker/fetches/rustc/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:2139:1
 INFO -  [crossbeam-utils 0.8.1]      |
 INFO -  [crossbeam-utils 0.8.1] 2139 | / atomic_int! {
 INFO -  [crossbeam-utils 0.8.1] 2140 | |     cfg(target_has_atomic = "16"),
 INFO -  [crossbeam-utils 0.8.1] 2141 | |     cfg(target_has_atomic_equal_alignment = "16"),
 INFO -  [crossbeam-utils 0.8.1] 2142 | |     stable(feature = "integer_atomics_stable", since = "1.34.0"),
 INFO -  [crossbeam-utils 0.8.1] ...    |
 INFO -  [crossbeam-utils 0.8.1] 2155 | |     u16 AtomicU16 ATOMIC_U16_INIT
 INFO -  [crossbeam-utils 0.8.1] 2156 | | }
 INFO -  [crossbeam-utils 0.8.1]      | |_- similarly named struct `AtomicU16` defined here
 INFO -  [crossbeam-utils 0.8.1]
ERROR -  [crossbeam-utils 0.8.1] error: aborting due to previous error
 INFO -  [crossbeam-utils 0.8.1]
 INFO -  [crossbeam-utils 0.8.1] For more information about this error, try `rustc --explain E0412`.

Gets picked up in a linux64 build and confuses the tooling.

Is there a way for autocfg to consume the output of rustc in a way that doesn't make it show up the logs of the build that calls into autocfg?

nical avatar Jan 08 '21 15:01 nical

Hmm, normally that output is captured and hidden, and even cargo build -v doesn't show anything, but cargo build -v -v does. https://github.com/rust-lang/cargo/blob/8e403e5e77e1fb5ebdba3094c5cf424bfc473f9e/src/cargo/core/compiler/custom_build.rs#L353-L370

We could add some debug/verbosity control in autocfg, redirecting rustc output to null if quiet -- and maybe that should be the default. It would probably need to be an environment variable, so you don't have to edit build scripts to affect this.

cuviper avatar Jan 08 '21 17:01 cuviper

Thanks for the quick answer. It looks like Firefox's build uses -vv intentionally since https://bugzilla.mozilla.org/show_bug.cgi?id=1473121 after some mismatched compiler versions had caused headaches.

I would greatly appreciate if autocfg was quiet by default including in -vv configurations, or if we could quiet it via an environment viable.

nical avatar Jan 11 '21 14:01 nical

Why did you close?

glandium avatar Feb 05 '21 20:02 glandium

Maybe I misunderstood, wasn't this resoved in #32 ?

nical avatar Feb 06 '21 10:02 nical

That's not merged yet though.

emilio avatar Feb 06 '21 16:02 emilio

My bad, I saw something landing into mozilla-central and thought it was resolved.

nical avatar Feb 06 '21 18:02 nical