mv std libs to library/ #73265
mv std libs to library/ #73265
Conversation
rust-highfive
added
the
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
☔ The latest upstream changes (presumably #69478) made this pull request unmergeable. Please resolve the merge conflicts. |
|
If we move the compiler crates into a directory as well, I'd expect the result to look roughly like this , i.e. all the high-level components at one level. |
|
I guess the idea was to move towards a world where std doesn't use x.py, e.g. we would later rename src to "rustc" or something... so i prefer to have different top-level directories. I'm ok with your proposal too, but the original mcp never mentioned moving all of the rustc crates one level deeper into another directory, which seems not as desirable... Also worth mentioning: @matklad proposed naming it "rt" (runtime) instead of "std"... still not really sure how i feel though. |
|
Well, no, the idea is that it's currently true that rust-lang/rust is somewhat unique in its directory structure. I would personally like to move to a world where we have more than just src at the top-level, e.g. we'd have something like this:
As I understand it, one of the survey results was that people felt overwhelmed navigating in the repository, as there's just so many crates all at the same level. A structure like this would hopefully help with that, at least easing people into the right "tree" of crates. Potentially each of these would also be its own workspace, to help with building things via normal Cargo, but that can be left to the future. |
|
All the high-level components in the root instead of Having a single directory with sources is convenient for things like |
|
I expect that most people will be touching only one of the root directories in any given PR (exceptions, of course, will exist). Hopefully that means that git clean's functionality still mostly works and this isn't too big a hit in that sense. The primary objection I've heard to this structure is that it adds a nesting layer we're currently missing (i.e., one more directory to descend down). I think that's inevitable if we keep the To be clear, though, I believe in this PR the intent is to only move the standard library and related ("runtime", I guess) crates into a top-level std directory with a nested src/, I believe (i.e., |
|
@mark-i-m is also standard library. |
Bikeshed warning. The naming can be based either on what the things do or on how the are named (which compiler? which library?) I'm not sure what I prefer, but the choice should probably be consistent at least. |
|
rustc + std seems like a good pairing, when we get to that point. In particular, I think "runtime" I'm not a fan of because it's not immediately discoverable -- most people are "surprised" in some sense to hear that Rust has a runtime -- and the runtime is really not all of std (much less test etc). |
|
One more suggestion - introduce inner |
|
Yes, same commit would be necessary. Git history should be mostly preserved with --follow though I think as we're not changing the files at all just renaming them (and git is pretty good about tracking that I think?) I do think that we should only move the files once regardless, in this PR. |
This comment has been minimized.
This comment has been minimized.
|
We do change the nesting depth, though, as previously there was no std directory in the path. IMO, that's a worthwhile trade-off, but I know that @bjorn3 and @lcnr felt differently. I don't really know how to try to deal with their objections, though, beyond just not adding the additional directory. Personally, I weigh the "standard layout" as more important than saving a click when navigating the tree on GitHub... but I guess that the calculus can reasonably be different from others. Maybe someone on T-compiler proper should make the call, or we can have another dedicated MCP (though I expect it to go equivalently). |
|
As a data point, rust-analyzer uses the equivalently deep layout with „useless“ src, |
|
VSCode uses a file search that is fuzzy enough to turn |
|
@rustbot modify labels: +I-nominated Nominating for discussion to get consensus on this proposal: #73265 (comment) |
|
Error: Label I-nominated can only be set by Rust team members Please let |
spastorino
added
I-nominated
T-compiler
|
I mean, I don't think Niko has that much on his plate 😛 |
301: fix for changed rustc directory layout r=RalfJung a=RalfJung This fixes xargo to work with rust-lang/rust#73265. We should wait until the next nightly is released so that CI tests a nightly with the new directories. Co-authored-by: Ralf Jung <[email protected]>
rustup for new folder layout Fixes the fallout from rust-lang/rust#73265. Blocked on a xargo release with japaric/xargo#301.
|
Perf triage: This was a slight regression. This seems unexpected. Perhaps metadata sizes increased so we're reading more from disk? It would be good to investigate this further. |
|
I don't know what to make of this other than maybe we messed up the layout of something in the processor caches? Where would one even start to debug something like this? |
|
My guess is that someone with pretty decent hardware, just to avoid it being really painful, would need to build rustc before/after this PR, i.e., on 9be8ffc and ac48e62 and run cachegrind on a rustc compilation of helloworld. The diff between those should give us a start of an idea for how to fix this. I've added this to my todo list. |
|
Adding to my todo as well.
With default options or something specific to reduce the noise? |
|
cachegrind diffs are usually noiseless for me, or nearly so. |
|
Looks like longer paths made hashing more expensive? If somebody wants to play with the raw data, here it is: I can also upload prebuilt Rust if somebody wants. |
|
That looks reasonable. I think the md5 hashing is presumably from encoding md5 hashes into debuginfo. Maybe we can consider some sort of partial hashing scheme -- many files are going to all be at some prefix, and we can pre-hash that prefix I guess? Not sure how feasible such a cache would be though. |
…crum tidy: Re-enable check for inline unit tests It regressed in rust-lang#73265 and compiler crates are no longer checked.
This is the first step in refactoring the directory layout of this repository, with further followup steps planned (but not done yet).
Background: currently, all crates are under src/, without nested src directories and with the unconventional
lib*prefixes (e.g.,src/libcore/lib.rs). This directory structures is not idiomatic and makes thesrc/directory rather overwhelming. To improve contributor experience and make things a bit more approachable, we are reorganizing the repo a bit.In this PR, we move the standard libs (basically anything that is "runtime", as opposed to part of the compiler, build system, or one of the tools, etc). The new layout moves these libraries to a new
library/directory in the root of the repo. Additionally, we remove thelib*prefixes and add nestedsrc/directories. The other crates/tools in this repo are not touched. So in summary:where
<crate>is:There was a lot of discussion about this and a few rounds of compiler team approvals, FCPs, MCPs, and nominations. The original MCP is rust-lang/compiler-team#298. The final approval of the compiler team was given here: #73265 (comment).
The name
librarywas chosen to complement a later move of the compiler crates to acompiler/directory. There was a lot of discussion around adding the nestedsrc/directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree, e.g., through GitHub's UI orcd), but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem, though there is some debate about how much this should apply to multi-crate projects. Overall, there seem to be more people in favor of nestedsrc/than against.After this PR, there are no dependencies out of the
library/directory except on thebuild_helper(or crates.io crates).