Build-std: Add builtin dependencies by adamgemmell · Pull Request #16675 · rust-lang/cargo

adamgemmell · 2026-02-25T17:40:41Z

This introduces a builtin source, the concept of opaque dependencies and implicit builtin dependencies and moves the -Zbuild-std implementation to use them, as part of rust-lang/rfcs#3875. While not strictly required for build-std=always, resolver support for builtin dependencies is required for the explicit builtin dependencies RFC and I wanted to ensure the implementation moving forward had that RFC in mind.

A builtin source is one which Cargo innately knows how to find, such as one included with the toolchain.
An opaque dependency isn't yet fully agreed upon, but is a possible future feature that "hides" transitive dependencies from the main resolve in order to reduce rebuilds. The build-std=always RFC makes reference to them. Currently, all opaque dependencies are builtin dependencies and vice versa.
An implicit builtin dependency is one that is injected by Cargo when there are no explicit builtin dependencies present on a package, for backwards compatibility reasons. Cargo injects implicit builtin dependencies for all non-build packages when -Zbuild-std is enabled.

This PR does this by:

Discovering library workspace members, and registering them as Sources to be queried by the PackageRegistry later.
Creating a default set of opaque, builtin dependencies from these members, and injects them in the RegistryQueryer.
The registry, when queried for a package satisfying one of these dependencies, returns builtin Summary. This package has no dependencies, because the dependency injected is opaque. This allows the resolve to succeed as normal without modifying the resolver itself. The intended behaviour, though untested, is to make use of all the patching/replacement logic already in the registry query.
Instead of the current -Zbuild-std unit generation step which attaches UnitDeps to each root of the std resolve, the main unit generation loop replaces the dummy Summarys with roots from the separate std resolve. Dependencies of the roots are then added afterwards.

This PR will inevitably break some behaviour of -Zbuild-std, and fixing that will come in future PRs (as will adding tests for it). A fair enough of that behaviour probably worked by accident. -Zbuild-std-features still works as I haven't touched the main std resolve and take Units directly from that. The non-build-std route is well tested already and I do not expect to find regressions there as the majority of this code is gated on -Zbuild-std.

At the time of writing, I'd particularly like to check behaviour with multiple targets and no_std targets before merging.

davidtwco · 2026-02-26T17:38:40Z

We aren't expecting that this will land prior to those RFCs being approved (unless Cargo want it to), the intent with this is just to get some feedback on the general direction for the implementation, we're happy to adjust as much or as little as required :) @adamgemmell will also be away for a couple of weeks starting next week, so we might not respond to feedback immediately.

epage · 2026-02-26T18:00:05Z

    /// A directory-based registry.
    Directory,
+    /// Package sources distributed with the rust toolchain
+    Builtin,


https://github.com/rust-lang/cargo/blob/master/crates/cargo-util-schemas/src/core/package_id_spec.rs is at least one other place that would need updating

This will impact the unique identifier for the packages from this source in cargo's json output when compiling, cargo metadata, cargo <cmd> -p, etc

I'll modify there too, and add a note to check the stdout in various use cases. The RFCs often make notes on what the output of various commands will be. Note that builtin doesn't actually appear in Units - they're all Path dependencies by that point.

An interesting point on cargo metadata is that we decided that we have an unresolved question regarding if deps of builtins should be shown on output, which will be a little hard here as they're not attached until unit generation.

epage · 2026-02-26T18:01:56Z

+                    .url
+                    .to_file_path()
+                    .expect("builtin sources should not be remote");
+                Ok(Box::new(PathSource::new(&path, self, gctx)))


Will using a PathSsource directly like this work?

This particularly could have interesting design questions

Moved this to a builtin source

epage · 2026-02-26T18:10:41Z

+        None
+    } else {
+        Some(builtins.iter())
+    };


I assume this is for implicit builtins. Is there a reason you chose to do this here?

Source replacements happen in dep_cache (see query) so it seemed simpler just to put this here for now. After digging a little more, it might just be the deprecated [replace] section though, in which case I can probably lift this out of the cache to a more appropriate place

This is in build_deps() now, which is a bit more appropriate. It could be moved up to the resolver activate function, but that's already massive, and moving it to PackageRegistry::query would involve modifying Summarys which are intended to be immutable.

epage · 2026-02-26T18:16:02Z

+        }
+    }
+
+    pub fn new_injected_builtin(name: InternedString) -> Dependency {


what do you see as the role of this compared to the other news?

The difference is that opaque is true (making a SourceId was also more complicated in a previous iteration of this patch). public should also be true now that I look closer.

epage · 2026-02-26T18:18:28Z

                )
            })?;

+        if dep.is_opaque() {


I'd like to find a way to ask the source for the opaque variant of the summary. The tricky thing will be that we need to work with both variants.

This pattern works well, see the new Summary::to_opaque_builtin_summary()

epage · 2026-02-26T18:20:20Z

+        // Injecting builtins earlier (somewhere with access to RustcTargetData) is needed instead of this
+        let home = std::env::var("HOME").expect("HOME is set");
+        let path = format!(
+            "file://{home}/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/"


The URL in source ids is public facing. I think we'll need something more generic and then a new Source

I definitely tried something more generic but found that it had to be valid at various points. Will experiment more with this.

epage · 2026-02-26T18:20:49Z

+        );
+        if name == "compiler_builtins" {
+            Self::from_url(&format!(
+                "builtin+{path}compiler-builtins/compiler-builtins"


why the special case?

It's the only direct dependency that isn't directly in the library folder. We need a better way of discovering packages for sure.

epage · 2026-02-26T18:21:35Z

            has_dev_units,
            crate::core::resolver::features::ForceAllTargets::No,
            dry_run,
+            true,


not really a fan of bool constants being used in parameter lists. Makes it a lot harder to figure what what is going on here

I've moved this specific bool, but there's probably scope to improve the passing around of the builtins path and dependencies set

epage · 2026-02-26T18:22:06Z

    keep_previous: Option<Keep<'_>>,
    specs: &[PackageIdSpec],
    register_patches: bool,
+    inject_builtins: bool,


Why do we need to tunnel this through? Not thrilled with this

This bool or the required logic behind it could probably be packaged into the workspace or it's gctx

adamgemmell

Thank you for leaving feedback. My latest set of changes does a bit of tidying and works towards getting the tests passing, but doesn't address these comments yet or otherwise make progress towards removing hacks.

View changes since this review

adamgemmell · 2026-03-18T17:20:22Z

+        None
+    } else {
+        Some(builtins.iter())
+    };


Source replacements happen in dep_cache (see query) so it seemed simpler just to put this here for now. After digging a little more, it might just be the deprecated [replace] section though, in which case I can probably lift this out of the cache to a more appropriate place

adamgemmell · 2026-03-18T17:24:10Z

+        }
+    }
+
+    pub fn new_injected_builtin(name: InternedString) -> Dependency {


The difference is that opaque is true (making a SourceId was also more complicated in a previous iteration of this patch). public should also be true now that I look closer.

adamgemmell · 2026-03-18T17:32:31Z

+        // Injecting builtins earlier (somewhere with access to RustcTargetData) is needed instead of this
+        let home = std::env::var("HOME").expect("HOME is set");
+        let path = format!(
+            "file://{home}/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/"


I definitely tried something more generic but found that it had to be valid at various points. Will experiment more with this.

adamgemmell · 2026-03-18T17:32:39Z

+        );
+        if name == "compiler_builtins" {
+            Self::from_url(&format!(
+                "builtin+{path}compiler-builtins/compiler-builtins"


It's the only direct dependency that isn't directly in the library folder. We need a better way of discovering packages for sure.

adamgemmell · 2026-03-19T10:40:20Z

    keep_previous: Option<Keep<'_>>,
    specs: &[PackageIdSpec],
    register_patches: bool,
+    inject_builtins: bool,


This bool or the required logic behind it could probably be packaged into the workspace or it's gctx

adamgemmell

I've addressed these comments. Excuse my big force-push, but I think the patch is easier to review with this commit structure

View changes since this review

adamgemmell · 2026-05-07T15:03:41Z

+                    .url
+                    .to_file_path()
+                    .expect("builtin sources should not be remote");
+                Ok(Box::new(PathSource::new(&path, self, gctx)))


Moved this to a builtin source

adamgemmell · 2026-05-07T15:05:02Z

                )
            })?;

+        if dep.is_opaque() {


This pattern works well, see the new Summary::to_opaque_builtin_summary()

adamgemmell · 2026-05-07T15:09:12Z

+        None
+    } else {
+        Some(builtins.iter())
+    };


This is in build_deps() now, which is a bit more appropriate. It could be moved up to the resolver activate function, but that's already massive, and moving it to PackageRegistry::query would involve modifying Summarys which are intended to be immutable.

adamgemmell · 2026-05-07T15:58:49Z

            has_dev_units,
            crate::core::resolver::features::ForceAllTargets::No,
            dry_run,
+            true,


I've moved this specific bool, but there's probably scope to improve the passing around of the builtins path and dependencies set

rustbot · 2026-05-07T16:03:40Z

r? @epage

rustbot has assigned @epage.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage, weihanglo

adamgemmell · 2026-05-08T17:06:14Z

Something I've noticed is that we may need to resolve std multiple times - if one supports std, the requested std (or test) crate in the resolve will enable features (like the proposed external-mem compiler-builtins` one) and crates that might not build on a no-std platform.

epage reviewed Feb 26, 2026

View reviewed changes

biscuitrescue mentioned this pull request Mar 3, 2026

fix: ignore implicit std dependencies in unused-crate-dependencies lint #16677

Merged

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. label Mar 6, 2026

adamgemmell force-pushed the dev/adagem01/opaque branch from 16dc1ab to ab7d8b0 Compare March 19, 2026 14:20

adamgemmell commented Mar 19, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

davidtwco mentioned this pull request Apr 14, 2026

build-std rust-lang/rust-project-goals#274

Open

10 tasks

adamgemmell force-pushed the dev/adagem01/opaque branch from ab7d8b0 to 8607d8c Compare May 7, 2026 15:58

rustbot added A-directory-source Area: directory sources (vendoring) A-workspaces Area: workspaces labels May 7, 2026

rustbot added the Command-add label May 7, 2026

adamgemmell commented May 7, 2026

View reviewed changes

adamgemmell changed the title ~~WIP: Builtin/opaque dependencies~~ Build-std: Add builtin dependencies May 7, 2026

adamgemmell marked this pull request as ready for review May 7, 2026 16:03

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 7, 2026

rustbot assigned epage May 7, 2026

adamgemmell added 9 commits May 7, 2026 18:00

Add new builtin SourceKind

ff3c11f

Add builtin Source

c21c068

Register builtin Sources and inject builtin deps

4fe54a8

Unit generation changes for opaque dependencies

76146f9

Fix mock-std tests

954a9ec

Do not use build-std for build dependencies

a8a8728

Remove builtin packages from the lockfile

8e72c73

Removing builtins from Locking/Adding etc status messages

0536a11

Support no-std targets and multiple targets

65e2e17

adamgemmell force-pushed the dev/adagem01/opaque branch from 8607d8c to 65e2e17 Compare May 8, 2026 16:55

rustbot added the A-infrastructure Area: infrastructure around the cargo repo, ci, releases, etc. label May 8, 2026

Conversation

adamgemmell commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidtwco commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

adamgemmell left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

adamgemmell left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented May 7, 2026

Uh oh!

adamgemmell commented May 8, 2026

adamgemmell commented Feb 25, 2026 •

edited

Loading

davidtwco commented Feb 26, 2026 •

edited

Loading

adamgemmell left a comment •

edited by rustbot

Loading

adamgemmell left a comment •

edited by rustbot

Loading