-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
rustc_metadata: Load metadata for indirect macro-only dependencies #69432
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
cc @rust-lang/compiler @ehuss @Aaron1011 |
Ideally we'd just make it lazy enough for it to be cheap unless the spans are used (e.g. by decoding a I'm curious if we have any crates on perf.r-l.o that may be affected: |
Awaiting bors try build completion |
[experiment] rustc_metadata: Load metadata for indirect macro-only dependencies Imagine this dependency chain between crates ``` Executable crate -> Library crate -> Macro crate ``` where "Library crate" uses the macros from "Macro crate" for some code generation, but doesn't reexport them any further. Currently, when compiling "Executable crate" we don't even load metadata for it, because why would we want to load any metadata from "Macro crate" if it already did all its code generation job when compiling "Library crate". Right? Wrong! Hygiene data and spans (#68686, #68941) from "Macro crate" still may need to be decoded from "Executable crate". So we'll have to load them properly. Questions: - How this will affect compile times for larger crate trees in practice? How to measure it? Hygiene/span encoding/decoding will necessarily slow down compilation because right now we just don't do some work that we should do, but this introduces a whole new way to slow down things. E.g. loading metadata for `syn` (and its dependencies) when compiling your executable if one of its library dependencies uses it. - We are currently detecting whether a crate reexports macros from "Macro crate" or not, could we similarly detect whether a crate "reexports spans" and keep it unloaded if it doesn't? Or at least "reexports important spans" affecting hygiene, we can probably lose spans that only affect diagnostics.
☀️ Try build successful - checks-azure |
Queued 341097d with parent d9a328a, future comparison URL. |
The performance diff looks like a noise, but I'm not sure what time is measured by perf.r-l.o. Also, why am I even asking this. |
|
Yeah, perhaps this can be just landed then, without further optimizations. The parts that can be potentially skipped (to what extent?) are |
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.
r=me if there are no concerns unrelated to perf left
(I'll leave this pending for a few days.) |
@bors r=eddyb |
📌 Commit 487c378 has been approved by |
☀️ Test successful - checks-azure |
Imagine this dependency chain between crates
where "Library crate" uses the macros from "Macro crate" for some code generation, but doesn't reexport them any further.
Currently, when compiling "Executable crate" we don't even load metadata for it, because why would we want to load any metadata from "Macro crate" if it already did all its code generation job when compiling "Library crate".
Right?
Wrong!
Hygiene data and spans (#68686, #68941) from "Macro crate" still may need to be decoded from "Executable crate".
So we'll have to load them properly.
Questions:
Hygiene/span encoding/decoding will necessarily slow down compilation because right now we just don't do some work that we should do, but this introduces a whole new way to slow down things. E.g. loading metadata for
syn
(and its dependencies) when compiling your executable if one of its library dependencies uses it.Or at least "reexports important spans" affecting hygiene, we can probably lose spans that only affect diagnostics.