compiler: validate.rs belongs next to what it validates #125483
Merged
Conversation
This file contains 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
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
rustbot
added
S-waiting-on-review
|
r? @oli-obk r=me with CI happy |
This comment has been minimized.
This comment has been minimized.
|
The Miri subtree was changed cc @rust-lang/miri |
|
@bors r=oli-obk |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 24, 2024
…te-to-mir-transform, r=oli-obk compiler: validate.rs belongs next to what it validates It's hard to find code that is deeply nested and far away from its callsites, so let's move `rustc_const_eval::transform::validate` into `rustc_mir_transform`, where all of its callers are. As `rustc_mir_transform` already depends on `rustc_const_eval`, the added visible dependency edge doesn't mean the dependency tree got any worse. This also lets us unnest the `check_consts` module. I did look into moving everything inside `rustc_const_eval::transform` into `rustc_mir_transform`. It turned out to be a much more complex operation, with more concerns and real edges into the `const_eval` crate, whereas this was both faster and more obvious.
|
@bors r- conflicts |
bors
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #125479) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@bors retry r- force |
bors
added
S-waiting-on-bors
workingjubilee
force-pushed
the
move-transform-validate-to-mir-transform
branch
from
e57c935 to
14fc3fd
Compare
|
"ooh, I'm a version control system with the ability to automatically merge branches together! except I can't do the MOST OBVIOUS POSSIBLE MERGE! use me because I'm so much better than all those other version control systems! bluh bluh!" |
|
@bors r=oli-obk |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 24, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#125467 (Only suppress binop error in favor of semicolon suggestion if we're in an assignment statement) - rust-lang#125483 (compiler: validate.rs belongs next to what it validates) - rust-lang#125485 (Migrate `run-make/rustdoc-with-output-dir-option` to `rmake.rs`) - rust-lang#125497 (Fix some SIMD intrinsics documentation) - rust-lang#125501 (Resolve anon const's parent predicates to direct parent instead of opaque's parent) - rust-lang#125503 (rustdoc-json: Add test for keywords with `--document-private-items`) - rust-lang#125519 (tag more stuff with `WG-trait-system-refactor`) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 24, 2024
Rollup merge of rust-lang#125483 - workingjubilee:move-transform-validate-to-mir-transform, r=oli-obk compiler: validate.rs belongs next to what it validates It's hard to find code that is deeply nested and far away from its callsites, so let's move `rustc_const_eval::transform::validate` into `rustc_mir_transform`, where all of its callers are. As `rustc_mir_transform` already depends on `rustc_const_eval`, the added visible dependency edge doesn't mean the dependency tree got any worse. This also lets us unnest the `check_consts` module. I did look into moving everything inside `rustc_const_eval::transform` into `rustc_mir_transform`. It turned out to be a much more complex operation, with more concerns and real edges into the `const_eval` crate, whereas this was both faster and more obvious.
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
It's hard to find code that is deeply nested and far away from its callsites, so let's move
rustc_const_eval::transform::validateintorustc_mir_transform, where all of its callers are. Asrustc_mir_transformalready depends onrustc_const_eval, the added visible dependency edge doesn't mean the dependency tree got any worse.This also lets us unnest the
check_constsmodule.I did look into moving everything inside
rustc_const_eval::transformintorustc_mir_transform. It turned out to be a much more complex operation, with more concerns and real edges into theconst_evalcrate, whereas this was both faster and more obvious.