Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot fing type AtomicU128 error #645

Closed
nical opened this issue Jan 8, 2021 · 4 comments
Closed

Cannot fing type AtomicU128 error #645

nical opened this issue Jan 8, 2021 · 4 comments
Labels

Comments

@nical
Copy link
Contributor

nical commented Jan 8, 2021

Hi,

In Firefox's build system we are running into this error:

 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`.

I am seeing it on a linux64 build, it might happen on other platforms as well.
It doesn't actually prevent the build from completing, but it confuses Firefox's build system and CI.

I'm not quite sure why this is happening. Is there a feature flag or something that could help with avoiding this error message, or something to adjust in crossbeam-utils?

@taiki-e
Copy link
Member

taiki-e commented Jan 8, 2021

This is the output when probe*/emit* methods of autocfg check if the code can be compiled. It has no effect on the build.

cfg.emit_type_cfg("core::sync::atomic::AtomicU128", "has_atomic_u128");

But I'm not sure why this is displayed to the user... I thought the content of the error on probe*/emit* would never be displayed.

cc @cuviper

@taiki-e
Copy link
Member

taiki-e commented Jan 8, 2021

INFO - [crossbeam-utils 0.8.1] cargo:rustc-cfg=has_atomic_u8

Hmm, does firefox's build system seem to get and parse the output of build scripts?
Then, if the output contains a string like "error", does firefox's build system seem to assume it as "an error has occurred"?

If the above assumptions are correct, this is a false positive of firefox's build system seem and probably could be fixed on firefox or autocfg side, but nothing on the crossbeam side.

@nical
Copy link
Contributor Author

nical commented Jan 8, 2021

I'm trying to figure out what our tooling is doing, but I don't think that we can easily work around it. The way we parse errors is more involved than matching for "error", of course, but this one looks like it is produced by rustc so it is hard to distinguish it from normal build breaking errors by looking at the formatting.

I hadn't realized that this is coming from autofcg which is outside of crossbeam.

@nical
Copy link
Contributor Author

nical commented Jan 8, 2021

Moved this to cuviper/autocfg#30.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants