Merge (most of) rustc_llvm into rustc_trans #41699
Labels
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
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
May 15, 2017
Make only rustc_trans depend on rustc_llvm With these changes, only rustc_trans depends directly on rustc_llvm (and no crate gained a new dependency on trans). This means changing LLVM doesn't rebuild librustc or rustc_metadata, only rustc_trans, rustc_driver and the rustc executable Also, rustc_driver technically doesn't know about LLVM any more (of course, it still handles a ton of options that conceptually refer to LLVM, but it delegates their implementation to trans). What I *didn't* implement was merging most or all of rustc_llvm into rustc_trans. I ran into a nasty bug, which was probably just a silly typo somewhere but I probably won't have the time to figure it out in the next week or two. I opened rust-lang#41699 for that step. Fixes rust-lang#41473
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
May 15, 2017
Make only rustc_trans depend on rustc_llvm With these changes, only rustc_trans depends directly on rustc_llvm (and no crate gained a new dependency on trans). This means changing LLVM doesn't rebuild librustc or rustc_metadata, only rustc_trans, rustc_driver and the rustc executable Also, rustc_driver technically doesn't know about LLVM any more (of course, it still handles a ton of options that conceptually refer to LLVM, but it delegates their implementation to trans). What I *didn't* implement was merging most or all of rustc_llvm into rustc_trans. I ran into a nasty bug, which was probably just a silly typo somewhere but I probably won't have the time to figure it out in the next week or two. I opened rust-lang#41699 for that step. Fixes rust-lang#41473
bors
added a commit
that referenced
this issue
May 16, 2017
Make only rustc_trans depend on rustc_llvm With these changes, only rustc_trans depends directly on rustc_llvm (and no crate gained a new dependency on trans). This means changing LLVM doesn't rebuild librustc or rustc_metadata, only rustc_trans, rustc_driver and the rustc executable Also, rustc_driver technically doesn't know about LLVM any more (of course, it still handles a ton of options that conceptually refer to LLVM, but it delegates their implementation to trans). What I *didn't* implement was merging most or all of rustc_llvm into rustc_trans. I ran into a nasty bug, which was probably just a silly typo somewhere but I probably won't have the time to figure it out in the next week or two. I opened #41699 for that step. Fixes #41473
Mark-Simulacrum
added
C-cleanup
|
Closing in favor of #45274 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
After #41565 is merged, only the rustc_trans crate depends on LLVM. In #41473, @eddyb proposed eliminating the rustc_llvm crate altogether once that is achieved and merging it into rustc_trans, but @whitequark pointed out that this might regress rebuild times when trans changed and LLVM didn't. A better solution might be to make rustc_llvm a
*-syscrate, i.e., it contains just the build script and the bare bones FFI definitions (extern blocksand types) while all the higher-level stuff moves into rustc_trans.The text was updated successfully, but these errors were encountered: