-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Cache derive proc macro expansion with incremental query #145354
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
Conversation
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
|
@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.
Cache derive proc macro expansion with incremental query
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
|
@bors try |
This comment has been minimized.
This comment has been minimized.
Cache derive proc macro expansion with incremental query
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
|
I looked into the benchmark failure on diesel, seems like I hold queries wrong somehow :) Any suggestions on what could be the case? Maybe the derived |
|
Ok I did a bit of debugging, and found a fun fact: |
|
Ok I found it, it's this. @nnethercote Do you think it's possible to make |
|
Technically, removing that I'm not actually sure where else |
|
Could you please specify what do you mean by "macro rules matching logic"? I tried removing I also thought that another alternative would be to wrap |
tests/incremental/derive_macro_expansion/auxiliary/derive_nothing.rs
Outdated
Show resolved
Hide resolved
|
CI is also failing. |
This comment was marked as resolved.
This comment was marked as resolved.
f3a462a to
05781ca
Compare
|
This PR was rebased onto a different main 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. |
|
@rustbot ready |
|
r=me after addressing the remaining nits and squashing commits. |
05781ca to
8fa2f69
Compare
|
@bors r=petrochenkov |
…henkov Cache derive proc macro expansion with incremental query This is a revival of rust-lang#129102, originally implemented by @futile. Since it looks like they are not active currently, I'd like to push this work forward. The first commit is squashed and rebased work from the original PR, with author attribution to futile. The rest of the commits are some additional comments that I created mostly for myself to understand what happens here. I also did some cleanups based on Vadim's review comments on the original PR, plus I refactored the TLS access a bit using `scoped_tls`. The biggest issue, as usually, are tests... I tried using `#[rustc_clean(..., loaded_from_disk = "derive_macro_expansion")]`, but the problem is that since this query cannot recover the original key from its hash, and thus its fingerprintstyle is `FingerprintStyle::Opaque`, [this](https://github.com/rust-lang/rust/blob/2fef0a30ae6b2687dfb286cb544d2a542f7e2335/compiler/rustc_incremental/src/persist/dirty_clean.rs#L388) crashes when I try to use `loaded_from_disk`. Any suggestions from someone who actually understands the query system would be welcome 😅 TODO: document the new unstable flag On a no-op change re-check of `octocrab 0.49` (which has a ton of `serde` derive proc macro invocations), this saves ~0.6s out of ~6s (so a ~10% win) on my PC. r? @petrochenkov
Rollup of 6 pull requests Successful merges: - #145354 (Cache derive proc macro expansion with incremental query) - #151123 (Support primitives in type info reflection) - #151178 (simplify words initialization using Rc::new_zeroed) - #151187 (Use `default_field_values` more in `Resolver`) - #151197 (remove lcnr from compiler review rotation) - #151203 (Revert `QueryStackFrame` split) r? @ghost
Rollup merge of #145354 - cache-proc-derive-macros, r=petrochenkov Cache derive proc macro expansion with incremental query This is a revival of #129102, originally implemented by @futile. Since it looks like they are not active currently, I'd like to push this work forward. The first commit is squashed and rebased work from the original PR, with author attribution to futile. The rest of the commits are some additional comments that I created mostly for myself to understand what happens here. I also did some cleanups based on Vadim's review comments on the original PR, plus I refactored the TLS access a bit using `scoped_tls`. The biggest issue, as usually, are tests... I tried using `#[rustc_clean(..., loaded_from_disk = "derive_macro_expansion")]`, but the problem is that since this query cannot recover the original key from its hash, and thus its fingerprintstyle is `FingerprintStyle::Opaque`, [this](https://github.com/rust-lang/rust/blob/2fef0a30ae6b2687dfb286cb544d2a542f7e2335/compiler/rustc_incremental/src/persist/dirty_clean.rs#L388) crashes when I try to use `loaded_from_disk`. Any suggestions from someone who actually understands the query system would be welcome 😅 TODO: document the new unstable flag On a no-op change re-check of `octocrab 0.49` (which has a ton of `serde` derive proc macro invocations), this saves ~0.6s out of ~6s (so a ~10% win) on my PC. r? @petrochenkov
|
Congratz @Kobzol, and thanks for seeing this through! The final code looks super nice. And thanks to @petrochenkov for all the reviews :) Looking forward to updating to the next nightly 😀 |
This is a revival of #129102, originally implemented by @futile. Since it looks like they are not active currently, I'd like to push this work forward.
The first commit is squashed and rebased work from the original PR, with author attribution to futile. The rest of the commits are some additional comments that I created mostly for myself to understand what happens here. I also did some cleanups based on Vadim's review comments on the original PR, plus I refactored the TLS access a bit using
scoped_tls.The biggest issue, as usually, are tests... I tried using
#[rustc_clean(..., loaded_from_disk = "derive_macro_expansion")], but the problem is that since this query cannot recover the original key from its hash, and thus its fingerprintstyle isFingerprintStyle::Opaque, this crashes when I try to useloaded_from_disk. Any suggestions from someone who actually understands the query system would be welcome 😅You can try it yourself on nightly with
RUSTFLAGS="-Zcache-proc-macros" cargo build.On a no-op change re-check of
octocrab 0.49(which has a ton ofserdederive proc macro invocations), this saves ~0.6s out of ~6s (so a ~10% win) on my PC.r? @petrochenkov