Add bootstrap option to compile a tool with features #142379
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rustbot
added
S-waiting-on-review
|
This PR modifies If appropriate, please update This PR modifies If appropriate, please update |
|
r? bootstrap |
Kobzol
reviewed
Jun 12, 2025
|
@rustbot ready Thanks for the review! I renamed to |
|
Thanks! @bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jun 13, 2025
Rollup of 10 pull requests Successful merges: - #134847 (Implement asymmetrical precedence for closures and jumps) - #141491 (Delegate `<CStr as Debug>` to `ByteStr`) - #141770 (Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code) - #142069 (Introduce `-Zmacro-stats`) - #142158 (Tracking the old name of renamed unstable library features) - #142221 ([AIX] strip underlying xcoff object) - #142340 (miri: we can use apfloat's mul_add now) - #142379 (Add bootstrap option to compile a tool with features) - #142410 (intrinsics: rename min_align_of to align_of) - #142413 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Jun 13, 2025
Rollup merge of #142379 - Stypox:bootstrap-tool-config, r=Kobzol Add bootstrap option to compile a tool with features Add an option to specify which features to build a tool with, e.g. it will be useful to build Miri with tracing enabled: ```toml tool-config.miri.features = ["tracing"] ``` See [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Passing.20--features.20to.20Miri.20build.20using.20.2E.2Fx.2Epy/with/523564773) for the options considered. If the final decision will be different than what I wrote now, I will update the code as needed. The reason why the option is `tool-config.miri.features` instead of something like `tool-features.miri` is to possibly allow adding more tool-specific configurations in the future. I didn't do any validation of the keys of the `tool-config` hashmap, since I saw that no validation is done on the `tools` hashset either. I don't like much the fact that features can be chosen by various places of the codebase: `Step`s can have some fixed `extra_features`, `prepare_tool_cargo` will add features depending on some bootstrapping options, and the newly added option can also contribute features to tools. However I think it is out of scope of this PR to try to refactor all of that (if it even is refactorable), so I left a comment in the codebase explaining all of the sources of features I could find.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Jun 14, 2025
Rollup of 10 pull requests Successful merges: - rust-lang/rust#134847 (Implement asymmetrical precedence for closures and jumps) - rust-lang/rust#141491 (Delegate `<CStr as Debug>` to `ByteStr`) - rust-lang/rust#141770 (Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code) - rust-lang/rust#142069 (Introduce `-Zmacro-stats`) - rust-lang/rust#142158 (Tracking the old name of renamed unstable library features) - rust-lang/rust#142221 ([AIX] strip underlying xcoff object) - rust-lang/rust#142340 (miri: we can use apfloat's mul_add now) - rust-lang/rust#142379 (Add bootstrap option to compile a tool with features) - rust-lang/rust#142410 (intrinsics: rename min_align_of to align_of) - rust-lang/rust#142413 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add an option to specify which features to build a tool with, e.g. it will be useful to build Miri with tracing enabled:
See this Zulip thread for the options considered. If the final decision will be different than what I wrote now, I will update the code as needed. The reason why the option is
tool-config.miri.featuresinstead of something liketool-features.miriis to possibly allow adding more tool-specific configurations in the future.I didn't do any validation of the keys of the
tool-confighashmap, since I saw that no validation is done on thetoolshashset either.I don't like much the fact that features can be chosen by various places of the codebase:
Steps can have some fixedextra_features,prepare_tool_cargowill add features depending on some bootstrapping options, and the newly added option can also contribute features to tools. However I think it is out of scope of this PR to try to refactor all of that (if it even is refactorable), so I left a comment in the codebase explaining all of the sources of features I could find.