Skip to content

Change bootstrap's tool.TOOL_NAME.features to work on any subcommand #143733

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

Merged
merged 3 commits into from
Jul 14, 2025

Conversation

Stypox
Copy link
Contributor

@Stypox Stypox commented Jul 10, 2025

This is a followup to #142379 to make the bootstrap option tool.TOOL_NAME.features work on any subcommand instead of just build (so also run/test/...). I also made the TOOL_NAME comparisons look at the tool path instead of the tool name to determine to which tool a TOOL_NAME refers to, so you can specify tools by path like in other places of the bootstrap (e.g. tool."tools/miri".features).

@rustbot
Copy link
Collaborator

rustbot commented Jul 10, 2025

r? @jieyouxu

rustbot has assigned @jieyouxu.
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 rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jul 10, 2025
@Stypox Stypox force-pushed the bootstrap-tool-config-any branch from 12c179f to 63d0487 Compare July 10, 2025 13:51
@Kobzol
Copy link
Member

Kobzol commented Jul 10, 2025

Nice improvement! Any particular reason for matching tools also by path though?

@Stypox
Copy link
Contributor Author

Stypox commented Jul 10, 2025

As far as I can understand tools are identified by their path, not by their name, e.g. here the descriptions don't contain a name (the "name" field is the fully qualified name of the class, so it does not count):

fn get_step_descriptions(kind: Kind) -> Vec<StepDescription> {

I read the code that is used to match x test miri with the test::Miri step, and it also accepts as equivalents x test tools/miri or x test src/tools/miri. So I wanted to keep this option also consistent with how tools are usually identified (and also because it feels more flexible, e.g. if two tools/libraries/... have the same name)

@Kobzol
Copy link
Member

Kobzol commented Jul 10, 2025

Hmm, I wouldn't say that they are identified by path, but I guess it depends on how you define "identified" :) In the tools array in bootstrap.toml, we already identify them by names, which are expected to be unique. I would keep this until we actually run into a use-case where we need to distinguish tools by their path.

@jieyouxu
Copy link
Member

I don't feel strongly either way; since you're already looking at this, r? @Kobzol

@rustbot rustbot assigned Kobzol and unassigned jieyouxu Jul 11, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 11, 2025

Kobzol is not on the review rotation at the moment.
They may take a while to respond.

Comment on lines 252 to 263
// build.tool.TOOL_NAME.features in bootstrap.toml allows specifying which features to enable
// for a specific tool. `extra_features` instead is not controlled by the toml and provides
// features that are always enabled for a specific tool (e.g. "in-rust-tree" for rust-analyzer).
// Finally, `prepare_tool_cargo` above here might add more features to adapt the build
// to the chosen flags (e.g. "all-static" for cargo if `cargo_native_static` is true).
builder
.config
.tool
.iter()
.filter(|(tool_name, _)| path.ends_with(tool_name))
.for_each(|(_, tool)| features.extend(tool.features.clone().unwrap_or_default()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion: if not already present, maybe we should remark that enabling features in tools which are not part of the internal "extra-features" preset might not always work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok thanks, I added a comment to bootstrap.example.toml

@Kobzol
Copy link
Member

Kobzol commented Jul 12, 2025

I'm fine with the change, but I'd like to just use the tool name, it's established practice in bootstrap, and I don't think we have a use-case to do it differently here.

@rustbot
Copy link
Collaborator

rustbot commented Jul 13, 2025

This PR modifies bootstrap.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

@Stypox
Copy link
Contributor Author

Stypox commented Jul 13, 2025

I'm fine with the change, but I'd like to just use the tool name, it's established practice in bootstrap, and I don't think we have a use-case to do it differently here.

Yeah makes sense, I changed the code to compare the tool name to only the last part of the path (aka the filename). Thanks for the review :-)

@Kobzol
Copy link
Member

Kobzol commented Jul 13, 2025

Thanks!

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Jul 13, 2025

📌 Commit d3e332e has been approved by Kobzol

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 13, 2025
@bors
Copy link
Collaborator

bors commented Jul 13, 2025

☔ The latest upstream changes (presumably #143888) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 13, 2025
bors added a commit that referenced this pull request Jul 13, 2025
Rollup of 8 pull requests

Successful merges:

 - #142885 (core: Add `BorrowedCursor::with_unfilled_buf`)
 - #143217 (Port #[link_ordinal] to the new attribute parsing infrastructure)
 - #143355 (wrapping shift: remove first bitmask and table)
 - #143448 (remote-test-client: Exit code `128 + <signal-number>` instead of `3`)
 - #143724 (Tidy cleanup)
 - #143820 (Fixed a core crate compilation failure when enabling the `optimize_for_size` feature on some targets)
 - #143850 (Compiletest: Simplify {Html,Json}DocCk directive handling)
 - #143880 (tests: Test line debuginfo for linebreaked function parameters)

Failed merges:

 - #143630 (Drop `./x suggest`)
 - #143733 (Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand)

r? `@ghost`
`@rustbot` modify labels: rollup
@Stypox Stypox force-pushed the bootstrap-tool-config-any branch from d3e332e to 940aa20 Compare July 14, 2025 07:38
@Stypox
Copy link
Contributor Author

Stypox commented Jul 14, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 14, 2025
@Kobzol
Copy link
Member

Kobzol commented Jul 14, 2025

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 14, 2025

📌 Commit 940aa20 has been approved by Kobzol

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 14, 2025
bors added a commit that referenced this pull request Jul 14, 2025
Rollup of 10 pull requests

Successful merges:

 - #143217 (Port #[link_ordinal] to the new attribute parsing infrastructure)
 - #143681 (bootstrap/miri: avoid rebuilds for test builds)
 - #143724 (Tidy cleanup)
 - #143733 (Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand)
 - #143850 (Compiletest: Simplify {Html,Json}DocCk directive handling)
 - #143875 (update issue number for `const_trait_impl`)
 - #143881 (Use zero for initialized Once state)
 - #143887 (Run bootstrap tests sooner in the `x test` pipeline)
 - #143917 (Change "allocated object" to "allocation".)
 - #143918 (Tier check cleanup)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 197ba7e into rust-lang:master Jul 14, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 14, 2025
rust-timer added a commit that referenced this pull request Jul 14, 2025
Rollup merge of #143733 - Stypox:bootstrap-tool-config-any, r=Kobzol

Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand

This is a followup to #142379 to make the bootstrap option `tool.TOOL_NAME.features` work on any subcommand instead of just build (so also run/test/...). I also made the `TOOL_NAME` comparisons look at the tool path instead of the tool name to determine to which tool a `TOOL_NAME` refers to, so you can specify tools by path like in other places of the bootstrap (e.g. `tool."tools/miri".features`).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants