-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Remove unused dependencies from compiler crates #86617
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
(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.