-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Remove unused dependencies from compiler crates #86617
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
rustc_data_structures has a dependency on crossbeam-utils but never uses it. It appears to have originally had this dependency in order to set the "nightly" feature; however, its other dependencies use a different version of crossbeam-utils, so this doesn't actually affect anything. Furthermore, in current crossbeam-utils, the "nightly" feature has become a no-op.
241398e
to
0f61739
Compare
Updated Cargo.lock in each commit. Useful command:
|
This comment has been minimized.
This comment has been minimized.
Unused since commit 622c48e ("Allow making `RUSTC_BOOTSTRAP` conditional on the crate name").
Unused since commit f141acf ("Move finalize_session_directory call out of cg_llvm").
…peck Unused since commit dc3eabd ("Store THIR in `IndexVec`s instead of an `Arena`").
Unused since commit 7d73e4c ("Remove ReScope").
Unused since commit 50e1ae1 ("Use ty::{IntTy,UintTy,FloatTy} in rustc").
Unused since commit cd7a011 ("Don't duplicate the extern providers once for each crate").
Unused since commit 8331dbe ("Add an Mmap wrapper to rustc_data_structures").
Unused since commit 4581d16 ("Move the query system to rustc_query_impl.").
Unused since commit 530a629 ("Remove pretty-print/reparse hack, and add derive-specific hack").
Unused since commit 6a32e79 ("stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union'").
Unused since commit 64af7ea ("Move SanitizerSet to rustc_target").
Unused since commit 50e1ae1 ("Use ty::{IntTy,UintTy,FloatTy} in rustc").
0f61739
to
7a9d419
Compare
Dropped the removal of |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 7a9d419 with merge 83f01bd5cc130c2f354a61775a6bb8dc2cf42b8f... |
☀️ Try build successful - checks-actions |
Queued 83f01bd5cc130c2f354a61775a6bb8dc2cf42b8f with parent 50a9081, future comparison URL. |
Finished benchmarking try commit (83f01bd5cc130c2f354a61775a6bb8dc2cf42b8f): comparison url. Summary: This benchmark run did not return any significant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Error: Label perf-regression can only be set by Rust team members Please let |
I just created the |
Although the bot said the result didn't have any significant changes, there're a lot of small regressions it seems. |
The benchmark results appear to be entirely noise/neutral, which is what I expected. I was primarily doing the perf run for the bootstrap timings; however, it looks like those timings are a simple sum of individual crate timings, which won't reflect any additional parallelism potentially made available by the looser dependencies. |
Yes, we currently use -j1 to reduce noise in the bootstrap measurements. @joshtriplett is there a reason this is still marked as a draft PR? |
(r=me if it's ready to go on your end) |
…Mark-Simulacrum Allow anyone to set `perf-regression` label The main purpose is to allow the triage bot to set the label: rust-lang#86617 (comment) r? `@Mark-Simulacrum`
I absolutely think that's the right thing to do in general. Is there some way to get perf measurements of a normal parallel build (and ideally the graph timings of "how early can things start"), without having to run them locally?
Just hadn't changed that yet. It started out as a draft because I wasn't sure if there were subtle dependencies I missed. I meant to change it to non-draft as soon as it built and showed a build performance improvement, and got distracted by the perf results not actually providing that information. |
No, not really. We in theory could add support for one-off collection on perf, but it's not trivial and doesn't seem particularly warranted. |
@bors r=Mark-Simulacrum |
📌 Commit 7a9d419 has been approved by |
☀️ Test successful - checks-actions |
Various compiler crates have dependencies that they don't appear to use. I used some scripting to detect such dependencies, filtered them based on some manual review, and removed those that do indeed appear to be entirely unused.