-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Shorten some dependency chains in the compiler #145390
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: master
Are you sure you want to change the base?
Shorten some dependency chains in the compiler #145390
Conversation
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. These commits modify compiler targets.
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Shorten some dependency chains in the compiler
This comment was marked as outdated.
This comment was marked as outdated.
35d6871
to
54f2e7b
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Shorten some dependency chains in the compiler
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
(Not sure if we'll see any changes in the bootstrap timings for this, because bootstrap is benchmarked with |
Finished benchmarking commit (0847c11): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 470.224s -> 470.269s (0.01%) |
@Kobzol Fair enough. It's really the CI time that I'm hoping improves here, and that does normal parallel builds. The |
@rust-timer build 0847c11 include=clap_derive |
Why do |
![]() Yeah that's noise. (you can't perf. the same commit twice, btw 😅) |
rustc_attr_parsing needs the id of the item the attribute was applied to for calling |
TIL. Would be nice to be able to re-run a single perf test. |
We're currently redesigning rustc-perf, maybe in the new version it might work, but I don't promise anything. |
54f2e7b
to
e0a9bde
Compare
Fixed some cases of trait impls that were using a |
This comment was marked as outdated.
This comment was marked as outdated.
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.
Should we just make this a module in rustc_span
?
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.
Should we just make this a module in
rustc_span
?
We could. It'd be straightforward enough to merge. I hadn't because rustc_span
is so widely used that I didn't want to make it any larger, and it generally seems easier to merge crates than to split them. (And because I thought that might be a harder sell.)
e0a9bde
to
6ef4052
Compare
This comment was marked as outdated.
This comment was marked as outdated.
6ef4052
to
fea6a65
Compare
☔ The latest upstream changes (presumably #145450) made this pull request unmergeable. Please resolve the merge conflicts. |
`rustc_errors` depends on numerous crates, solely to implement its `IntoDiagArg` trait on types from those crates. Many crates depend on `rustc_errors`, and it's on the critical path. We can't swap things around to make all of those crates depend on `rustc_errors` instead, because `rustc_errors` would end up in dependency cycles. Instead, move `IntoDiagArg` into `rustc_error_messages`, which has far fewer dependencies, and then have most of these crates depend on `rustc_error_messages`. This allows `rustc_errors` to drop dependencies on several crates, including the large `rustc_target`. (This doesn't fully reduce dependency chains yet, as `rustc_errors` still depends on `rustc_hir` which depends on `rustc_target`. That will get fixed in a subsequent commit.)
Some crates depend on `rustc_hir` but only want `HirId` and similar id types. `rustc_hir` is a heavy dependency, since it pulls in `rustc_target`. Split these types out into their own crate `rustc_hir_id`. This allows `rustc_errors` to drop its direct dependency on `rustc_hir`. (`rustc_errors` still depends on `rustc_hir` indirectly through `rustc_lint_defs`; a subsequent commit will fix that.)
`rustc_lint_defs` uses `rustc_hir` solely for the `Namespace` type, which it only needs the static description from. Use the static description directly, to eliminate the dependency on `rustc_hir`. This reduces a long dependency chain: - Many things depend on `rustc_errors` - `rustc_errors` depends on `rustc_lint_defs` - `rustc_lint_defs` depended on `rustc_hir` prior to this commit - `rustc_hir` depends on `rustc_target`
…hir` `rustc_mir_dataflow` only uses `DefId`, which is a re-export from `rustc_span`.
`rustc_traits` only uses `DefId`, which is a re-export from `rustc_span`.
fea6a65
to
76ec917
Compare
This PR was rebased onto a different master commit! Check out the changes with our |
(I recommend reviewing this commit by commit.)
One of the long dependency chains in the compiler is:
rustc_errors
.rustc_errors
depended on many things prior to this PR, includingrustc_target
,rustc_type_ir
,rustc_hir
, andrustc_lint_defs
.rustc_lint_defs
depended onrustc_hir
prior to this PR.rustc_hir
depends onrustc_target
.rustc_target
is large and takes a while.This PR breaks that chain, through a few steps:
IntoDiagArgs
trait, fromrustc_errors
, moves earlier in the dependency chain. This allowsrustc_errors
to stop depending on a pile of crates just to implementIntoDiagArgs
for their types.rustc_hir_id
out ofrustc_hir
, so crates that just needHirId
and similar don't depend on all ofrust_hir
(and thusrustc_target
).rustc_lint_defs
stop depending onrustc_hir
.