-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
bootstrap: consolidate subcommand parsing and matching #96003
bootstrap: consolidate subcommand parsing and matching #96003
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
r? @jyn514 |
@bors delegate=jyn514 |
✌️ @jyn514 can now approve this pull request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like the right approach, thanks so much! My only concern is that there are a lot of unrelated changes along with the fix - I'd prefer to leave things as they are unless necessary, since bootstrap is very prone to regressions.
pub fn get_help(build: &Build, kind: Kind) -> Option<String> { | ||
let step_descriptions = Builder::get_step_descriptions(kind); | ||
if step_descriptions.is_empty() { | ||
return None; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was part of the logic for printing the hint to run with -h -v
to see available paths if and only if there are paths that we could list for that subcommand.
For example, in Rust now if you run ./x.py clippy -h
it will suggest Run './x.py clippy -h -v' to see a list of available paths.
, but when you run ./x.py clippy -v -v
it doesn't actually list any paths.
My assumption was that all of these commands could have useful paths to pass to them but I might be mistaken about that. It seems like check and clippy would take paths just like build does, but it kinda seems like clippy runs for "everything" in the build graph anyway and passing paths doesn't do much.
Is this specific list of commands which could print a list of paths for help text intentional and the others (clippy, check, fix) are supposed to be excluded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My assumption was that all of these commands could have useful paths to pass to them but I might be mistaken about that.
This is not currently true. There are several related issues:
- Not all commands accept paths.
x clippy
, as you noticed, runs on the whole tree.x clean
does the same. - Some commands that do not accept paths do not check whether a path was passed -
x clippy src/bootstrap
is exactly the same as an unconditionalx clippy
. - Some commands the do accept paths do not go through
StepDescription
. For examplex fmt src/bootstrap
is perfectly valid and limits the changes to bootstrap itself, but there is noimpl Step for Format
description, becauseStep
has no way to say "all paths".
Fixing those issues should wait for follow up PRs, I think. In the meantime, can you do the following:
- Remove
clippy
andfix
from thecheck
arm and down to thevec![]
arm.clippy
is certainly not supported with paths, andfix
has been broken for ages. - Change the code in
usage
that callsget_help
to panic if-h -v
is called for a subcommand that does not support paths. We should give the user an idea that something is broken rather than silently ignoring the flag.
"Run `./x.py {} -h -v` to see a list of available paths.", | ||
subcommand.as_str() | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this refactoring necessary for the fix? Unrelated changes like this make the PR harder to review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's related to the logic in get_help()
, see my comments there. I might have had the wrong idea about the desired behavior in this area.
@rustbot label -S-waiting-on-review +S-waiting-on-author +A-rustbuild +C-cleanup |
Thanks for the review and guidance! I'll get things cleaned up. Regarding the bigger changes in It's not great for help text to say "run this other command for more info" when that other command doesn't actually have more info. I went the direction of providing that info (available build target paths) in more cases, but maybe not printing the |
@aswild I think you took the right approach, I misunderstood the issues you were running into. I left suggestions in #96003 (comment) :) |
There's several places where the x.py command names are matched as strings, leading to some inconsistencies and opportunities for cleanup. * Add Format, Clean, and Setup variants to builder::Kind. * Use Kind to parse the x.py subcommand name (including aliases) * Match on the subcommand Kind rather than strings when handling options and help text. * Several subcommands don't display any paths when run with `-h -v` even though the help text indicates that they should. Fix this and refactor so that manually keeping matches in sync isn't necessary. Fixes rust-lang#95937
c6d27bb
to
870cb8e
Compare
Thanks for the suggestions! I implemented them and force-pushed a new patch set. |
@bors r+ |
📌 Commit 870cb8e has been approved by |
Thanks for the PR! |
Thanks for the opportunity to contribute to Rust! Compilers are big and scary but I can wrap my head around tooling and build systems |
…anup, r=jyn514 bootstrap: consolidate subcommand parsing and matching There's several places where the x.py command names are matched as strings, leading to some inconsistencies and opportunities for cleanup. * Add Format, Clean, and Setup variants to builder::Kind. * Use Kind to parse the x.py subcommand name (including aliases) * Match on the subcommand Kind rather than strings when handling options and help text. * Several subcommands don't display any paths when run with `-h -v` even though the help text indicates that they should. Fix this and refactor so that manually keeping matches in sync isn't necessary. Fixes rust-lang#95937
☀️ Test successful - checks-actions |
Finished benchmarking commit (1dec35a): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
This seems to be a possible case of the @rustbot label: +perf-regression-triaged |
There's several places where the x.py command names are matched as
strings, leading to some inconsistencies and opportunities for cleanup.
options and help text.
-h -v
eventhough the help text indicates that they should. Fix this and refactor
so that manually keeping matches in sync isn't necessary.
Fixes #95937