-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Change paths for dist
command to match the components they generate
#90684
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
I think we should pick one (components seem like a good idea, though I'm not sure it was a purposeful choice historically) and just have that, rather than trying to have multiple names. |
My worry was that people would try to use the old names and get confused that they no longer work ... but I agree it does make more sense to just have them match the component, I'll do that. |
dist
command that match the components they generatedist
command to match the components they generate
Can you check if there are any overlapping (i.e., same name) strings under dist now? I recall having to make a manual change a bit ago because the path(...) was the same for two dist steps or something like that. |
@Mark-Simulacrum they look unique:
|
That last one looks like not the name of the produced component, but then I don't think build-manifest is either. So seems OK for now -- maybe a future PR can spend some time cleaning this up. @bors r+ |
📌 Commit 026a25b9a720942895374c0cdb4bbd095e5613ce has been approved by |
This comment has been minimized.
This comment has been minimized.
@bors r=Mark-Simulacrum |
📌 Commit 3366327 has been approved by |
Before, you could have the confusing situation where the command to generate a component had no relation to the name of that component (e.g. the `rustc` component was generated with `src/librustc`). This changes the name to make them match up.
@bors r+ |
📌 Commit d42a391 has been approved by |
⌛ Testing commit d42a391 with merge 8f778c82c4bcbcccb083345a6378c3debe817114... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
☀️ Test successful - checks-actions |
Finished benchmarking commit (4205481): comparison url. Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
It looks like html5ever-check locally seems to improve, not regress, on this benchmark for me, though by a tiny instruction count -- 63,015 less instructions in early_resolve_ident_in_lexical_scope. I'm not sure what causes this but the inconsistency with actual results seems a little weird here; not clear exactly what could cause that. The wall-time for IncrUnchanged seems to be ~0.3 seconds. I'm seeing the same results for the incr-patched println test case, so it seems like a consistent improvement. |
It's strange to me this would change performance at all, bootstrap isn't distributed period and the only other thing that changed in PR was some shell scripts. |
Well, at the very least, our artifacts currently contain the commit hash in a bunch of places as we remap paths to it. Maybe we should not do that -- so that a PR like this could be expected to produce identical binaries -- but we don't currently. |
Before, you could have the confusing situation where the command to
generate a component had no relation to the name of that component (e.g.
the
rustc
component was generated withsrc/librustc
). This changesthe name to make them match up.