Skip to content

bootstrap: Don't pass Kind to some places that don't need it - #160191

Open
Zalathar wants to merge 3 commits into
rust-lang:mainfrom
Zalathar:unkind
Open

bootstrap: Don't pass Kind to some places that don't need it#160191
Zalathar wants to merge 3 commits into
rust-lang:mainfrom
Zalathar:unkind

Conversation

@Zalathar

Copy link
Copy Markdown
Member

The current CLI step's Kind was being passed deep into some selector-matching code that doesn't seem to actually need it. It seems that the kind associated with a step's ShouldRun paths/aliases always comes from that step, so proceeding to compare it against the step's kind later can never fail and doesn't achieve anything.

As far as I can tell, this is a relic of #91965 that (due to subsequent changes) doesn't do anything useful and also doesn't make a lot of conceptual sense.

This PR therefore removes the Kind parameter from PathSet::check, and removes the Kind field from TaskPath.

Touching TaskPath causes a lot of churn in snapshot tests, but there don't seem to be any changes in actual behaviour.

@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 30, 2026
@rustbot

rustbot commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

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

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: bootstrap
  • bootstrap expanded to 6 candidates
  • Random selection from Mark-Simulacrum, clubby789, jieyouxu

@jieyouxu jieyouxu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks, this seems right.

I wonder if Kind was previously used to do... Kind-dependent resolution 😰

@bors r+

View changes since this review

Comment on lines +419 to +420
// This order is important for retro-compatibility, as `starts_with` was introduced later.
p.path.ends_with(needle) || p.path.starts_with(needle)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Remark (unrelated to this PR): I really dislike this behavior of both prefix and postfix matching, it's a nightmare, but alas

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

It makes sense that you would want both ./x test compiler and ./x test rustc_middle to test the crate compiler/rustc_middle, for example.

But yeah, selector matching is several layers of inside-out spaghetti stacked on top of each other, so it's a nightmare to touch anything at the moment.

@@ -1,137 +1,137 @@
---
source: src/bootstrap/src/core/builder/cli_paths/tests.rs
expression: test --skip=tests --skip=coverage-map --skip=coverage-run --skip=library --skip=tidyselftest

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Remark: hm, interesting

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I think this weirdness is because the “expression” isn't actually checked by insta, so it became stale after #159131 which changed the expression but didn't invalidate the actual snapshotted results.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ah, yeah, makes sense

@rust-bors

rust-bors Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 8740040 has been approved by jieyouxu

It is now in the queue for this repository.

@rust-bors rust-bors Bot 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 30, 2026
@jieyouxu

Copy link
Copy Markdown
Member

Actually, r=me once PR CI is 🍏, just in case
@bors r-

@rust-bors rust-bors Bot 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 30, 2026
@rust-bors

rust-bors Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved.

View changes since this unapproval

@jieyouxu jieyouxu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Since apparently I failed to click the "Approve" button... 😆

View changes since this review

@rust-log-analyzer

This comment has been minimized.

@jieyouxu

Copy link
Copy Markdown
Member

Oh interesting, does this change linkcheck skipping? 🤔 (Can't dig into this rn, but can check later)

@Zalathar

Copy link
Copy Markdown
Member Author

Oh interesting, does this change linkcheck skipping? 🤔 (Can't dig into this rn, but can check later)

Given that #91965 mentions linkchecker specifically, this might be a real problem. 😿

@jieyouxu

jieyouxu commented Jul 30, 2026

Copy link
Copy Markdown
Member

For linkcheck I think we generally need to skip it for stage 1... 🤔

EDIT: i.e. #156792 (but I forgot to backlink to the original PR where this was discussed, argh)

@Zalathar

Zalathar commented Jul 30, 2026

Copy link
Copy Markdown
Member Author

I think something relevant is happening in Builder::run_default_doc_steps, where we end up creating a bunch of step descriptions that are based on Kind::Doc rather than self.kind.

EDIT: I think it's bogus for that function to be calling self.run_step_descriptions.

@Zalathar

Copy link
Copy Markdown
Member Author

Further notes:

  • There are few steps (including ./x test linkchecker) that want to do the equivalent of ./x doc before proceeding, so they call Builder::run_default_doc_steps.
  • The implementation of run_default_doc_steps ends up re-invoking some of the command-line handling stuff with a fake subcommand Kind::Doc and a fake empty list of command-line selectors &[].
  • The underlying command-line-handling code is not prepared to actually deal with that, so details from the “real” arguments leak into things like --skip handling, causing some crates to not be documented.
  • Passing around the Kind then serves as a bizarre inside-out hack to prevent some of that interference, so getting rid of the hack breaks things.

@Zalathar

Copy link
Copy Markdown
Member Author

I'm contemplating a narrower hack where we pass a two-value enum down through run_step_descriptions into maybe_run that signals “this is actually for run_default_doc_steps, so don't do any --skip handling”.

That's still super gross, but it might be a net improvement.

@Zalathar

Copy link
Copy Markdown
Member Author

Pushed an update with a hack to forcibly disable --skip handling during run_default_doc_steps (diff).

Not sure if we actually want to do this, but I figure we might as well check whether it would work.

@Zalathar

Copy link
Copy Markdown
Member Author

Pushed a different workaround that avoids the skip_mode enum, and instead duplicates just the relevant parts of run_step_descriptions (diff).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

4 participants