Skip to content

Compile warning while compiling libstd with Xargo (use of #[allow_internal_unstable]) #58515

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

Closed
johnthagen opened this issue Feb 16, 2019 · 4 comments

Comments

@johnthagen
Copy link
Contributor

I am seeing a build warning when building libstd in a simple "Hello World" using Xargo.

     Running `rustc --crate-name std /home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/lib.rs --color always --crate-type dylib --crate-type rlib --emit=dep-info,link -C prefer-dynamic -C opt-level=z -C panic=abort -C codegen-units=1 -C metadata=6a8dec85bcef7069 --out-dir /tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/tmp/xargo.5pshJ0HoG6fd/target/release/deps --extern alloc=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/liballoc-e8747074132386de.rlib --extern compiler_builtins=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/libcompiler_builtins-8346f6da3599dc11.rlib --extern core=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/libcore-54d405ee7be45efa.rlib --extern libc=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/liblibc-ba56a133f24710be.rlib --extern panic_abort=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/libpanic_abort-e431905f180ae625.rlib --extern rustc_demangle=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/librustc_demangle-cfd6040da80adc90.rlib --extern rustc_asan=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/librustc_asan-6890241a7ab63939.rlib --extern rustc_lsan=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/librustc_lsan-a6443c9ae07827d9.rlib --extern rustc_msan=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/librustc_msan-3ad28f250536833b.rlib --extern rustc_tsan=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/librustc_tsan-c59201cb2ed07266.rlib --extern unwind=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/deps/libunwind-420cd95ff7b95cd4.rlib --sysroot /home/travis/.xargo/HOST -Z force-unstable-if-unmarked -l dl -l rt -l pthread -L native=/tmp/xargo.5pshJ0HoG6fd/target/x86_64-unknown-linux-gnu/release/build/compiler_builtins-6b448c751373bea5/out`
warning: allow_internal_unstable expects list of feature names. In the future this will become a hard error. Please use `allow_internal_unstable(foo, bar)` to only allow the `foo` and `bar` features
  --> /home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/../stdsimd/crates/std_detect/src/detect/arch/x86.rs:82:1
   |
82 | #[allow_internal_unstable]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^

Full build job: https://travis-ci.org/johnthagen/min-sized-rust/jobs/494234235

Project source: https://github.com/johnthagen/min-sized-rust/tree/master/xargo

Build command (using latest nightly):

https://github.com/johnthagen/min-sized-rust/blob/master/.travis.yml#L32-L34

$ rustup component add rust-src;
$ cargo install xargo --force;
$ xargo build --target x86_64-unknown-linux-gnu --release --verbose
@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Feb 16, 2019

cc @oli-obk - #58098

I suspect this just needs a nightly update to happen but not sure.

@johnthagen
Copy link
Contributor Author

And for quick reference, the nightly version used in the build was:

$ rustc --version
rustc 1.34.0-nightly (a9410cd1a 2019-02-15)

@oli-obk
Copy link
Contributor

oli-obk commented Feb 16, 2019

yea this will go away after we get a bootstrap compiler update and then are able to update stdsimd

@Mark-Simulacrum
Copy link
Member

In that case I'm going to close as tracking this separately seems not that useful (we'll do both of those naturally anyway); it's only a warning anyway.

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

No branches or pull requests

3 participants