Restrict sysroot crate imports to those defined in this repo.

[Diggsey]

It's common to import dependencies from the sysroot via extern crate rather than use an explicit cargo dependency, when it's necessary to use the same dependency version as used by rustc itself. However, this is dangerous for crates.io crates, since rustc may not pull in the dependency on some targets, or may pull in multiple versions. In both cases, the extern crate fails to resolve.

To address this, re-export all such dependencies from the appropriate rustc_* crates, and use this alias from crates which would otherwise need to use extern crate.

See #143492 for an example of the kind of issue that can occur.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/compiletest

cc @jieyouxu

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @TaKO8Ki

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[RalfJung]

The Miri changes LGTM, except the ones in the vendored file where only the header at the top should be edited.

I'm fine with having these Miri changes here, seems easier to do this centrally than coordinate half a dozen PRs.

[oli-obk]

Do you think it is feasible to add an internal lint that rejects extern crate items where the crate name doesn't start with rustc_ or sth like that?

[Diggsey]

@oli-obk I'll look into this. How does testing work for sub-trees? Would each sub-tree need its own copy of the lint, or do the subtree repos have some way to run rust-wide lints?

[RalfJung]

"internal" lints live in rustc like normal lints, but are gated behind a nightly-only flag. Miri enables them in their CI, I don't know if ./x check miri also enables them.

[oli-obk]

We have a list of internal lints that rustc has and enables everywhere. We'd have to limit it to crates with #![allow(internal_features)] or sth like it. Most other lints are obviously limited to that as they look for e.g. TyKind .

[RalfJung]

Not sure what you mean about restricting it, the lints need -Zunstable-options -Wrustc::internal to be enabled, right?

[oli-obk]

Ah right, my bad

[Diggsey]

I've updated the PR and added a lint, so I think this is ready to go.

There is one problem which is that the lint is an internal rustc lint and so is not automatically applied to all of the tool crates which it should be. It will be necessary to opt-in to rustc internal lints in each of the tools. Clippy already opts in, and possibly Miri? But other tool crates will have to opt-in.

[antoyo]

The cg_gcc part looks good to me.

[bjorn3]

cg_clif changes LGTM

[RalfJung]

Miri changes LGTM.

[Dylan-DPC]

@Diggsey any updates on this ? thanks

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[Diggsey]

@Dylan-DPC I've rebased and implemented @oli-obk's requested changes.