-
Notifications
You must be signed in to change notification settings - Fork 14k
bootstrap: Split out Step::is_really_default from Step::should_run
#148965
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
base: main
Are you sure you want to change the base?
Conversation
|
r? @clubby789 rustbot has assigned @clubby789. Use |
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.
I'm a big fan of the changes, I think this is much less confusing than before. However, I would like to discuss the name of is_really_default with the team, because I still find it confusing to read...
| // named `builder` for IDE autocompletion. | ||
| let _ = builder; | ||
| Self::DEFAULT | ||
| } |
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.
Discussion: maybe a name like finalized_default? I kinda hate that name too, it reminds me of the convoluted compiler lint level decoration logic... Anyway, 'finalized' in the sense that there's a hierarchy or precedence ordering:
Step::DEFAULTis the "base" default.is_really_defaultorfinalized_defaultcan "override" this base default subject to conditions.
(2) then finally determines if a Step is eligible to run.
I say this because is_really_default I find quite confusing to read...
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.
I don't think is_really_default is a great name, but on the other hand I do appreciate that it conveys a suitable amount of “you should probably read the actual docs for this oddly-named function instead of assuming that it does something intuitive”.
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.
... Yeah. Let's land this now as is_really_default, if we can come up with a better name later, we can always do that in a follow-up.
| /// Called to allow steps to register the command-line paths that should | ||
| /// cause them to run. |
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.
Discussion:
command-line paths
I guess this is a path / path filter. Discussing in #t-infra/bootstrap > Path filters in bootstrap @ 💬 on what we actually call these
./x test xxx
^-- what is this called?
|
@bors r+ rollup |
One of the confusing things about bootstrap's
Step::should_runis that it combines two loosely-related but non-overlapping responsibilities:./x test compiler, this allows bootstrap to know what steps “compiler” should translate intoDEFAULT = trueshould actually run or not, when no paths/aliases are explicitly specified./x test, this allows bootstrap to know which steps to run by defaultThis PR splits out the latter of those responsibilities into a separate
is_really_defaultassociated function.A small number of steps were using
ShouldRun::lazy_default_conditionto specify a condition that should not be run repeatedly if possible, e.g. because it queries external tools. Those steps now perform memoization via fields inBuilderinstead.