Remove librustc_codegen_utils. #45276
Labels
A-codegen
Area: Code generation
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
Second offender: #45381. |
bors
added a commit
that referenced
this issue
Dec 19, 2017
Move collector to librustc_mir::monomorphize cc #44334 and #45276 * I moved the collector to rustc_mir * I renamed `TransItem` to `MonoItem`. _(I still need to fix up comments and variable names)_ * I got rid of `common.rs` and `monomorphize.rs` from `librustc_trans_utils`. I moved most of the functionality into `TyCtxt`. I realized that the `librustc_trans_utils::common.rs` was just copy pasted from `librustc_trans::common.rs`. Should I also get rid of the `librustc_trans::common.rs` in this PR? Most of the functionality seems a bit useless, I decided to put some of it into `TyCtxt` but maybe that is not the correct action here. Should I also get rid of `librustc_trans_utils` completely here? Or should I do it in a separate PR?
XAMPPRocky
added
C-cleanup
|
Seems we don't have librustc_trans_utils anymore? |
|
@kzys It got renamed in the meanwhile. |
Centril
added a commit
to Centril/rust
that referenced
this issue
Mar 21, 2020
Refactorings to get rid of rustc_codegen_utils r? @eddyb cc rust-lang#45276 After this, the only modules left in `rustc_codegen_utils` are - `link`: a bunch of linking-related functions (many dealing with file names). These are mostly consumed by save analysis, rustc_driver, rustc_interface, and of course codegen. I assume they live here because we don't want a dependency of save analysis on codegen... Perhaps they can be moved to librustc? - ~`symbol_names` and `symbol_names_test`: honestly it seems odd that `symbol_names_test` is not a submodule of `symbol_names`. It seems like these could honestly live in their own crate or move to librustc. Already name mangling is exported as the `symbol_name` query.~ (move it to its own crate) I don't mind doing either of the above as part of this PR or a followup if you want.
|
I believe this should be closed by #69965 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Added by #44085, doesn't serve a real purpose. Common utility functions belong in
librustc.The text was updated successfully, but these errors were encountered: