CI accepted doctests that do not build (due to missing feature gates)

[RalfJung]

This will stop reproducing when #114837 lands, but right now you can click here, click on "Run", and playground opens and you click on "Run" again, and you get an error. How did CI accept a doctest that does not build?

[waynr]

Also worth noting, I believe the doctests were passing for me when I ran them locally as well.

[RalfJung]

Yeah I checked and they pass locally for me as well. I just don't understand how that's possible. Either rustdoc is doing something odd or this is caused by the special bootstrap magic. But I can't think of how that would lead to just ignoring a "missing feature gate" error...

It is a somewhat special feature gate since it is about the path, not the item. So maybe something in #95956 is going wrong in combination with how bootstrap sets up the sysroot, or so...? Cc @rust-lang/bootstrap @yaahc

[onur-ozkan]

Thanks for the ping on bootstrap team, will check it by the coming weekend.

[RalfJung]

FWIW when running the tests via https://github.com/rust-lang/miri-test-libstd/, the feature gate error does show up as expected. That's how I noticed this to begin with. That repo runs the tests without bootstrap but there are also some other differences (like setting the miri-test-libstd feature gate which clears out most of the crate -- but not when cfg(doctest) is set). With x.py I don't even know which crate core in the doctest refers to -- does it set up a sysroot and use that, or is this running "without sysroot" like the build of the main core crate?

[onur-ozkan]

The main problem behind this issue is that this function

rust/compiler/rustc_passes/src/stability.rs

Lines 848 to 851 in 32aa405

	/// Check whether a path is a `use` item that has been marked as unstable.
	///
	/// See issue #94972 for details on why this is a special case
	fn is_unstable_reexport(tcx: TyCtxt<'_>, id: hir::HirId) -> bool {

can't detect unstable attributes which are defined at the top level of the modules when it's the bootstrap environment. cc @yaahc

If you swap

rust/library/core/src/error.rs

Line 2 in 32aa405

#![unstable(feature = "error_in_core", issue = "103765")]

with error_generic_member_access in this module, then same problem will happen for error_generic_member_access and error_in_core errors will work as expected.

I am not really sure if we should keep the T-bootstrap label for this issue.

[RalfJung]

can't detect unstable attributes which are defined at the top level of the modules when it's the bootstrap environment.

But what is different in bootstrap that makes this happen?

[onur-ozkan]

But what is different in bootstrap that makes this happen?

This is why..

rust/src/bootstrap/builder.rs

Lines 1725 to 1727 in b60e31b

	if !mode.is_tool() {
	cargo.env("RUSTC_FORCE_UNSTABLE", "1");
	}

sorry for the noise, was debugging/looking on the wrong point:)

[RalfJung]

I still don't get it. Note that all other unstable items are properly detected. E.g., removing the error_generic_member_access feature from the test errors as expected. This only affects some unstable things, like error_in_core -- the ones that are "path unstable" rather than "item unstable".

Why does that env var affect "path unstable" but not "item unstable"?

[onur-ozkan]

Can you add force-unstable-if-unmarked rustcflag flag on miri-side tests? If you still encounter the errors(related to error_in_core), it is likely that there is another mysterious bootstrap magic that remains to be identified.

[RalfJung]

No need to bother Miri. We can just try this file:

#![allow(unused)]
use core::error::{request_ref, Request};

fn main() {}

With rustc +nightly --edition 2018 this errors as expected. But with rustc +nightly --edition 2018 -Zforce-unstable-if-unmarked it builds despite the missing feature!