Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Basic standard library support. #7216
This is not intended to be useful to anyone. If people want to try it, that's great, but do not rely on this. This is only for experimenting and setting up for future work.
This adds a flag
Note: I can probably break some of the refactoring into smaller PRs if necessary.
The general concept here is to use two resolvers, and to combine everything in the Unit graph. There are a number of changes to support this:
I currently went with a strategy of linking the standard library dependencies using
For future PRs
Questions for this PR
alexcrichton left a comment
This is some amazing progress @ehuss, can't thank you enough again for leading the charge here on this!
These are some amazingly detailed and thorough thougts. I'd want to make sure they're not lost! Are you figuring that these would become issues on the wg-std-aware Cargo repository after this PR is merged?
This is also true of
I think this is fine for now in general to be clear, but I'd like to see more config codified in rust-lang/rust's
(reading your comments I think you and I are already thinking the same thing...)
This matches my thinking as well. I think, however, we should probably "stabilize" an interface between Cargo/libstd about this. For example if libstd is built in unwinding mode it should activate everything necessary to get the
FWIW I think your refactoring of removing
I'm curious to hear more about this, what else is needed for these platforms? I think like musl/wasi will have difficulty in the sense that they assume a C standard library is already built, but are you thinking of other issues? (I'm not sure what the difficulty is with windows-gnu for example)
Mind sending me a gist of what this looks like?
I wrote this in the comments inline below as well, but I think that
This is a really good question!
I think I'd ideally like to see two forms of testing. One is that it actually uses the rust-lang/rust components and such and runs full integration tests. I think these tests can be pretty few and far between though.
Otherwise I think it'd be good if we can create a mock "libstd dependency set" for Cargo itself which we use in tests. Sort of like how we stub out the registry. Ideally these mock crates would just reexport the actual core/std crates in Rust itself (somehow? Maybe some magical test-only feature that makes them visible?) and would be empty crates otherwise to compile very quickly.
With the idea of a "mock root set up by Cargo" this would be easy enough to test perhaps?
This is fine I think to cover later, this feature is purely a "let's just smash things until it works" feature so if it works otherwise it's not needed.
Otherwise it's impossible to produce dynamic programs at all in Rust (e.g. rustc wouldn't exist). It's a bad reason.
Rust, oh-so-long ago, only supported the
For almost all use cases other than the compiler itself having a dylib is basically extraneous and not helpful.
It's an extremely longstanding bug in Cargo that you can't configure crate types at build time. For std-aware cargo there's basically zero reason for Cargo to produce a dynamic library of the standard library.
Thanks for taking a look!
Yes. I wanted to hold off in case any of them became non-issues through the course of updating this PR.
Yep. My goal with this was to try to avoid needing to make any changes to rust-lang/rust at first. We can then start rolling out any changes there that will make this easier later.
Hm, you just made me think of something. When running
Oh dear, that's a good point! I think though we'd functionally want to do what libstd does today which is to compile everything with
Ah ok I see what you mean. I do think that those will cause issues and will be good to track! Of course not a blocker for this though
Hm ok, that does indeed look horrifyingly confusing. I'll try to help debug once this goes through as well
Hm so in theory optimization settings should affect symbol visibility to the point of causing linker errors. That's just theory though, and libstd is always a special child, so there's probably something wrong here or there. I would need to dig into it more locally though to figure it out.
FWIW I'm personally feeling pretty good about landing this, so @ehuss I don't mind waiting if you've got blockers you'd prefer to handle first but I think it's otherwise fine to start opening issues and adding comments for what should be removed when and then r+ this
Sep 3, 2019
10 checks passed
Thanks a lot for implementing this! I don't know if this is the right place to share feedback, so please tell me if there is a more appropriate place!
In summary, I would say that this MVP is already able to replace most uses of
You should be able to set