1685697 - Permanent failure lines for successful build tasks: [crossbeam-utils 0.8.1] error[E0412]: cannot find type `AtomicU128` in module `core::sync::atomic`

Status: RESOLVED FIXED

(Developer Infrastructure :: General, defect, P3)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Build tasks like this one always contain the following failure lines:

[crossbeam-utils 0.8.1] error[E0412]: cannot find type AtomicU128 in module core::sync::atomic
[crossbeam-utils 0.8.1] error: aborting due to previous error
[crossbeam-utils 0.8.1] error[E0412]: cannot find type AtomicU128 in module core::sync::atomic
[crossbeam-utils 0.8.1] error: aborting due to previous error

Log: https://treeherder.mozilla.org/logviewer?job_id=326168466&repo=autoland

[task 2021-01-08T11:14:57.335Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u64
[task 2021-01-08T11:14:57.336Z] 11:14:57    ERROR -  [crossbeam-utils 0.8.1] error[E0412]: cannot find type `AtomicU128` in module `core::sync::atomic`
[task 2021-01-08T11:14:57.336Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]     --> <anon>:1:38
[task 2021-01-08T11:14:57.336Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]      |
[task 2021-01-08T11:14:57.336Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] 1    |   pub type Probe = core::sync::atomic::AtomicU128;
[task 2021-01-08T11:14:57.336Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]      |                                        ^^^^^^^^^^ help: a struct with a similar name exists: `AtomicU16`
[task 2021-01-08T11:14:57.336Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]      |
[task 2021-01-08T11:14:57.337Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]     ::: /builds/worker/fetches/rustc/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:2139:1
[task 2021-01-08T11:14:57.337Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]      |
[task 2021-01-08T11:14:57.337Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] 2139 | / atomic_int! {
[task 2021-01-08T11:14:57.337Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] 2140 | |     cfg(target_has_atomic = "16"),
[task 2021-01-08T11:14:57.337Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] 2141 | |     cfg(target_has_atomic_equal_alignment = "16"),
[task 2021-01-08T11:14:57.338Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] 2142 | |     stable(feature = "integer_atomics_stable", since = "1.34.0"),
[task 2021-01-08T11:14:57.338Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] ...    |
[task 2021-01-08T11:14:57.338Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] 2155 | |     u16 AtomicU16 ATOMIC_U16_INIT
[task 2021-01-08T11:14:57.338Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] 2156 | | }
[task 2021-01-08T11:14:57.338Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]      | |_- similarly named struct `AtomicU16` defined here
[task 2021-01-08T11:14:57.338Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]
[task 2021-01-08T11:14:57.338Z] 11:14:57    ERROR -  [crossbeam-utils 0.8.1] error: aborting due to previous error
[task 2021-01-08T11:14:57.339Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1]
[task 2021-01-08T11:14:57.339Z] 11:14:57     INFO -  [crossbeam-utils 0.8.1] For more information about this error, try `rustc --explain E0412`.

This is a regression from bug 1683294. Such permanent 'failure' lines will be also shown when the builds actually fail and will confuse Try users and code sheriffs. Please fix the underlying issue.

Comment 1

[Nicolas Silva [:nical]]

I don't understand what is going on here, I filed https://github.com/crossbeam-rs/crossbeam/issues/645 upstream.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

So what's happening is that autocfg is spawning a rustc process, and the output of that process is just being redirected to the build script output.

Since we build with --verbose we show the build script output and think it's an error.

I think ideally autocfg should have a way (env var? something else? Maybe it should just do it by default) to eat the rustc output.

Comment 3

[Nicolas Silva [:nical]]

I filed https://github.com/cuviper/autocfg/issues/30

Comment 4

[Intermittent Failures Robot]

1 failures in 2956 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform breakdown:

• windows2012-64: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1685697&startday=2021-01-04&endday=2021-01-10&tree=all

Comment 6

[Nicolas Silva [:nical]]

Moving to a component that looks more like it is related to the build system.

Comment 7

[Nicolas Silva [:nical]]

Relevant comment from upstream issue:

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

Perhaps we could get away with not using the very verbose mode?

Comment 8

[Nicolas Silva [:nical]]

https://treeherder.mozilla.org/jobs?repo=try&revision=4dbc18aacc994fb415fc7636d9df1c96f37f2dfe seems to confirm that building with -v instead of -vv removes the error from the log.

Comment 9

[Nicolas Silva [:nical]]

Attachment: Bug 1685697 - Build rust code in verbose mode instead of very verbose.

This works around an issue with our log parser picking up false positive errors from autocfg.
Autocfg is used by some of our dependencies in build scripts to detect whether certain features are support by invoking rustc and seeing whether it manages to build with them. When running cargo in very verbose mode, rustc output from these autocfg invocation is visible to our error parser.

Building in very verbose mod was introduced in bug 1473121 to help with investigating errors caused by mismatched toolchains. It would be nice to reenable it but that will require upstream changes in autocfg.

Comment 10

[Mike Hommey [:glandium]]

Attachment: Bug 1685697 - Hide the rustc output from autocfg.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/69fdccc97cb0
Hide the rustc output from autocfg. r=emilio

Comment 12

[Intermittent Failures Robot]

20 failures in 623 pushes (0.032 failures/push) were associated with this bug yesterday.

Repository breakdown:

• autoland: 20

Platform breakdown:

• linux64-aarch64: 18
• windows2012-64: 1
• osx-cross: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1685697&startday=2021-01-15&endday=2021-01-15&tree=all

Comment 13

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/69fdccc97cb0

Comment 14

[Intermittent Failures Robot]

39 failures in 3810 pushes (0.01 failures/push) were associated with this bug in the last 7 days.

This is the #15 most frequent failure this week.

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. **

Repository breakdown:

• autoland: 39

Platform breakdown:

• windows2012-64: 2
• osx-cross: 2
• linux64-aarch64: 35

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1685697&startday=2021-01-11&endday=2021-01-17&tree=all