std-using paths work just fine in 2018 edition #![no_std]

[cramertj]

Example:

#![no_std]

use std::io::{Write, stdout};

fn main() {
    stdout().write(b"oh dear...\n").unwrap();
}

rustc happily accepts this when passed --edition 2018. This makes sense-- it was always possible to reach std in #![no_std] crates if you wrote extern crate std;, but now that extern crate is redundant, that is no longer necessary. Unfortunately, that also means that projects attempting to test for #![no_std] compatibility no longer have an easy way to check that they've correctly cut out all std-based dependencies.

We could special case std paths to not work via the "extern prelude". This would work, but would require projects that want to optionally use std (who currently use #[cfg(feature = "std")] extern crate std;) to continue using extern crate std;, which is awkward both because (1) it'd be the only place where extern crate ever gets used in the Rust of the future and (2) you'd have to write paths like crate::std::... in order to refer to your locally-mounted extern crate std, which is all sorts of strange.

Another option could be to make cargo and rustc aware of "no-std-ness" and allow some sort of flag or option which could make std un-linkable, perhaps usable by something like this Cargo.toml:

[dependencies]
std = { optional = true }

[features]
default = ["std"]

However, this seems like a fairly complex addition and begins to interact with the various std-aware-cargo proposals.

Another option: do nothing. This isn't a huge deal, and as @MajorBreakfast pointed out, the issue will often be caught in CI by testing against targets that don't have std support. There are also various proposals like the portability lint that could obsolete whatever change we come up with here.

[joshtriplett]

I'd certainly like to see std handled through cargo someday. In the meantime, how difficult would it be to have #![no_std] make std disappear from the prelude?

[petrochenkov]

std is not in the prelude when #![no_std] is enabled.

In the "anchored path" model (using terminology from #53130) imports still desugar into absolute paths (::std::io::... aka extern::std::io::...) and such paths can refer to any crates that can be found in crate search directories, not only those from the extern prelude.

[petrochenkov]

In the "uniform path" model std cannot be accessed via relative paths in no-std crates (since it's not in the prelude), but still can be accessed with explicit absolute paths:

#![no_std]

use std::io; // ERROR
use ::std::io; // or `use extern::std::io;`, OK

[joshtriplett]

such paths can refer to any crates that can be found in crate search directories, not only those from the extern prelude.

Then let me rephrase my original suggestion: how difficult would it be to have #![no_std] remove std from whatever list of crates that :: searches? (And are there any crates other than std that this applies to?)

[petrochenkov]

Not difficult at all, just weird.
A lint would probably be more appropriate for this situation.

[cramertj]

@joshtriplett I also suggested this and discussed the tradeoffs in my post above:

We could special case std paths to not work via the "extern prelude". This would work, but would require projects that want to optionally use std (who currently use #[cfg(feature = "std")] extern crate std;) to continue using extern crate std;, which is awkward both because (1) it'd be the only place where extern crate ever gets used in the Rust of the future and (2) you'd have to write paths like crate::std::... in order to refer to your locally-mounted extern crate std, which is all sorts of strange.

I don't think it's a slam-dunk, and I agree with @petrochenkov that a warning is probably a good solution in this case, since crates could conditionally deny the warning or allow it based on their std feature gate.

[nikomatsakis]

@petrochenkov so, just to be clear:

I think that right now if you do use some_crate::bar, we will go and search the lib path for some_crate, just as we used to with extern crate. This presumably is why std works, right?

I remember finding that somewhat surprising to start. I expected us only to use the crate names that were given explicitly to rustc via --extern for such paths, and to require explicit extern crate in order to actually search the disk.

I guess though that if we were to try and change it, we would have to make sure we handle core, std, and friends correctly here.

[petrochenkov]

@nikomatsakis

I think that right now if you do use some_crate::bar, we will go and search the lib path for some_crate, just as we used to with extern crate.

Yes, right now with 2018 edition enabled use path; will go and search library directories (unless uniform_paths is enabled) and ::path will always go and search library directories.

These discussions are scattered over several threads, and in one of them a few people, including @eddyb , expressed the desire to disable this directory search, or use it only for crates explicitly passed with --extern without path argument.

[aturon]

We discussed this issue in the lang team meeting today, and arrived at a rough consensus which I'll try to lay out here. cc @rust-lang/lang

• We do not search library directories in Rust 2018, except for the three currently-stable libraries (core, std, proc_macro) which are whitelisted.

• We provide a lint against using std, which is normally allow by default, but is deny by default in no-std cases. Crate authors providing their own std flag can conditionally allow the lint based on this flag.

• We will provide an unstable mechanism to specify additional root crates in Cargo.toml, which will be passed in via --extern, so that you can get access to e.g. rustc crates.

  • In the long run, this mechanism will provide a way to stabilize new root crates and provide access to them.

[SimonSapin]

We provide a lint against using std, which is normally allow by default, but is deny by default in no-std cases.

In this new world, how does one achieve the existing pattern that goes like this? #![no_std] #![cfg(feature = "std")] extern crate std;

[joshtriplett]

@SimonSapin #![cfg_attr(not(feature="std"), no_std)] might help.