Change paths for dist command to match the components they generate#90684
Change paths for dist command to match the components they generate#90684bors merged 1 commit intorust-lang:masterfrom
dist command to match the components they generate#90684Conversation
|
(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
rustccomponent was generated withsrc/librustc). This changesthe name to make them match up.