Skip to content

Conversation

@Zalathar
Copy link
Member

One of the very silly things about directive processing in compiletest is that for each directive in the test file, we proceed to check it against dozens of different directive names in linear sequence, without any kind of indexed lookup, and without any early-exit after a known directive name is found (unless a panic occurs).

This PR is a big step away from that, by taking the iter_directives loop in TestProps::load_from and making all of its directive processing dispatch to a hashtable of individual name-specific handlers instead.


The handler system is set up in a way that should allow us to add capabilities or change the implementation as needed, without having to mass-modify the existing handlers (e.g. this is why the handler and multi_handler functions are used).


This PR is focused on mass-migrating all of the TestProps directive processing into handlers. Most of the resulting handlers could obviously be simplified further (e.g. by avoiding the redundant name checks that were needed in the pre-migration code), but I've avoided doing any such simplifications in this PR to keep its scope limited and make reviewing easier.

The patches in this PR have been arranged so that the main migration can be inspected with git diff --color-moved --color-moved-ws=ignore-all-space to verify that it moves all of the relevant lines intact, without modifying or discarding any of them.

r? jieyouxu

@rustbot
Copy link
Collaborator

rustbot commented Oct 22, 2025

Some changes occurred in src/tools/compiletest

cc @jieyouxu

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

@rustbot rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc labels Oct 22, 2025
@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 Oct 22, 2025
@Zalathar
Copy link
Member Author

Running a bunch of try jobs to check for unforeseen problems:

@bors try jobs=x86_64-msvc-1,i686-msvc-1,x86_64-mingw-1,test-various,armhf-gnu,aarch64-apple,dist-i586-gnu-i586-i686-musl

rust-bors bot added a commit that referenced this pull request Oct 22, 2025
compiletest: Migrate `TestProps` directive handling to a system of named handlers

try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-apple
try-job: dist-i586-gnu-i586-i686-musl
@rust-bors

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented Oct 22, 2025

☀️ Try build successful (CI)
Build commit: dd79bb4 (dd79bb4ea51e0e37cea8fc6fdaef3a0586643b34, parent: 37ec98f5d33c0876a9ffa5ee17dc0895659efe37)

@jieyouxu
Copy link
Member

jieyouxu commented Oct 26, 2025

I'll review this tmrw/Tuesday. EDIT: make that this weekend.

@bors
Copy link
Collaborator

bors commented Nov 3, 2025

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

@rustbot

This comment has been minimized.

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

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

Thank you, and sorry for the delay. This is much nicer than the previous matching logic.

View changes since this review

props.compile_flags.extend(flags);
}
}),
handler("edition", |config, ln, props| {
Copy link
Member

Choose a reason for hiding this comment

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

Discussion: for the fixed directive names, i.e. the edition, revisions, pp-exact and normalize-*, should we also introduce a named constant for them?

I was mostly thinking if we might be able to document them alongside the revision impl via rustdoc, but that won't work necessarily for 'dynamic' directive names.

Copy link
Member Author

Choose a reason for hiding this comment

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

I was thinking of eventually moving away from the named constants, at least for the vast majority of handlers where once the directive name has been matched, the handler body no longer cares what the actual name was.

Currently most of the handlers mention the directive name twice, once for matching and once again when calling the appropriate parse method. But I see that as a temporary arrangement, because overhauling the individual parse methods was out of scope for this PR.

Copy link
Member

Choose a reason for hiding this comment

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

Hm yeah. That does make a lot of sense. This is perfectly fine for this PR 👍

@jieyouxu
Copy link
Member

jieyouxu commented Nov 9, 2025

You can r=me once addressing the nits.
@rustbot author

@rustbot rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Nov 9, 2025
@rustbot

This comment has been minimized.

This step consists of two changes:

- Renaming `self` to `props`
- Inserting temporary comments to preserve line breaks

This will make it easier to verify that the main migration commit preserves all
of the lines being migrated.
Use `git diff --color-moved --color-moved-ws=ignore-all-space` (or similar) to
verify that the directive-processing lines have been moved without changes.
@rustbot
Copy link
Collaborator

rustbot commented Nov 10, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@Zalathar
Copy link
Member Author

Resolved conflict with #148510, which also makes the test a bit nicer since we can just use KNOWN_DIRECTIVE_NAMES_SET instead of building our own temporary set.

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

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

Thanks, you can r=me once PR CI is green.

View changes since this review

@Zalathar
Copy link
Member Author

@bors r=jieyouxu

@bors
Copy link
Collaborator

bors commented Nov 10, 2025

📌 Commit 33e9911 has been approved by jieyouxu

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 10, 2025
Zalathar added a commit to Zalathar/rust that referenced this pull request Nov 10, 2025
compiletest: Migrate `TestProps` directive handling to a system of named handlers

One of the very silly things about directive processing in compiletest is that for each directive in the test file, we proceed to check it against dozens of different directive names in linear sequence, without any kind of indexed lookup, and without any early-exit after a known directive name is found (unless a panic occurs).

This PR is a big step away from that, by taking the `iter_directives` loop in `TestProps::load_from` and making all of its directive processing dispatch to a hashtable of individual name-specific handlers instead.

---

The handler system is set up in a way that should allow us to add capabilities or change the implementation as needed, without having to mass-modify the existing handlers (e.g. this is why the `handler` and `multi_handler` functions are used).

---

This PR is focused on mass-migrating all of the `TestProps` directive processing into handlers. Most of the resulting handlers could obviously be simplified further (e.g. by avoiding the redundant name checks that were needed in the pre-migration code), but I've avoided doing any such simplifications in this PR to keep its scope limited and make reviewing easier.

The patches in this PR have been arranged so that the main migration can be inspected with `git diff --color-moved --color-moved-ws=ignore-all-space` to verify that it moves all of the relevant lines intact, without modifying or discarding any of them.

r? jieyouxu
Zalathar added a commit to Zalathar/rust that referenced this pull request Nov 10, 2025
compiletest: Migrate `TestProps` directive handling to a system of named handlers

One of the very silly things about directive processing in compiletest is that for each directive in the test file, we proceed to check it against dozens of different directive names in linear sequence, without any kind of indexed lookup, and without any early-exit after a known directive name is found (unless a panic occurs).

This PR is a big step away from that, by taking the `iter_directives` loop in `TestProps::load_from` and making all of its directive processing dispatch to a hashtable of individual name-specific handlers instead.

---

The handler system is set up in a way that should allow us to add capabilities or change the implementation as needed, without having to mass-modify the existing handlers (e.g. this is why the `handler` and `multi_handler` functions are used).

---

This PR is focused on mass-migrating all of the `TestProps` directive processing into handlers. Most of the resulting handlers could obviously be simplified further (e.g. by avoiding the redundant name checks that were needed in the pre-migration code), but I've avoided doing any such simplifications in this PR to keep its scope limited and make reviewing easier.

The patches in this PR have been arranged so that the main migration can be inspected with `git diff --color-moved --color-moved-ws=ignore-all-space` to verify that it moves all of the relevant lines intact, without modifying or discarding any of them.

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

Labels

A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc 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.

4 participants