-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
librustc should not depend on librustc_llvm #41473
Comments
Indeed, only |
Wouldn't that degrade compile times on rebuild? |
Does EDIT For the latter we should use the |
I think it's nontrivial, and statically linking LLVM (I dynamically link, personally) can take a lot of time with the default set of targets (I recall linking it for straight minutes). |
@whitequark Yeah we can still separate that out I think, but move anything that's not imports into what is currently |
Currently, |
@arielb1 Yeah I think we want to split it so the backend provides file -> metadata blob functionality, and |
Yeah. That would also be the Right Thing for targets with "unconventional linking". |
This impacts me a lot, as essentially all my rustc work for the next few weeks or more consists of modifying LLVM, occasionally librustc_llvm, and rarely librustc_trans. So I'd volunteer to fix it. I could use some details on what this "file -> metadata blob" API should look like, though. Please elaborate here or ping me on IRC. |
@rkruppe maybe something like this?
|
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
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
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
I'm adding something to librustc_llvm and changing it rebuilds a lot of rustc libraries. @eddyb said this should not be the case.
The text was updated successfully, but these errors were encountered: