Skip to content
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.

Sign up for GitHub

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

Jump to bottom

mv src/lib{std,core,alloc,test,etc} std/lib{std,core,alloc,test,etc} #298

Closed
2 of 4 tasks
mark-i-m opened this issue May 29, 2020 · 3 comments
Closed
2 of 4 tasks

mv src/lib{std,core,alloc,test,etc} std/lib{std,core,alloc,test,etc} #298

mark-i-m opened this issue May 29, 2020 · 3 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@mark-i-m
Copy link
Member

mark-i-m commented May 29, 2020 •
edited
Loading

What is this issue?

This is a major change proposal, which means a proposal to make a notable change to the compiler -- one that either alters the architecture of some component, affects a lot of people, or makes a small but noticeable public change (e.g., adding a compiler flag). You can read more about the MCP process on https://forge.rust-lang.org/.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

MCP Checklist

  • MCP filed. Automatically, as a result of filing this issue:
    • The @rust-lang/wg-prioritization group will add this to the triage meeting agenda so folks see it.
    • A Zulip topic in the stream #t-compiler/major changes will be created for this issue.
  • MCP seconded. The MCP is "seconded" when a compiler team member or contributor issues the @rustbot second command. This should only be done by someone knowledgable with the area -- before seconding, it may be a good idea to cc other stakeholders as well and get their opinion.
  • Final comment period (FCP). Once the MCP is approved, the FCP begins and lasts for 10 days. This is a time for other members to review and raise concerns -- concerns that should block acceptance should be noted as comments on the thread, ideally with a link to Zulip for further discussion.
  • MCP Accepted. At the end of the FCP, a compiler team lead will review the comments and discussion and decide whether to accept the MCP.
    • At this point, the major-change-accepted label is added and the issue is closed. You can link to it for future reference.

A note on stability. If your change is proposing a new stable feature, such as a -C flag, then a full team checkoff will be required before the feature can be landed. Often it is better to start with an unstable flag, like a -Z flag, and then move to stabilize as a secondary step.

TL;DR

Summarize what you'd like to do in a sentence or two, or a few bullet points.

Move std/core/alloc/proc_macro/test/etc libraries to a new std/ directory at the top level of the repo to make contributing to them a bit less intimidating.

EDIT: after discussion [on zulip][z], we want to also make the crate layouts of these crates a bit more "normal" by giving them an actual src/ directory. So for example: std/libstd/Cargo.toml and std/libstd/src/*

EDIT2: actually my previous edit is now more of an open question... what do we want the path to be?

Links and Details

Add a few paragraphs explaining your design. The level of detail should be
sufficient for someone familiar with the compiler to understand what you're
proposing. Where possible, linking to relevant issues, old PRs, or external
documents like LLVM pages etc is very useful.

The MCP was inspired by this discussion and suggestion from Mark.

One of the early takeaways from the survey so far has been that people (especially new contributors) tend feel overwhelmed by the complexity/size of the codebase.
The basic motivation of this MCP is to make it feel less intimidating to contribute to libstd/core/alloc/etc and to disentangle them from the compiler a bit, so it feels less "complex" to (especially new) contributors.

EDIT: after discussion [on zulip][z], we want to also make the crate layouts of these crates a bit more "normal" by giving them an actual src/ directory. So for example: std/libstd/Cargo.toml and std/libstd/src/*

EDIT2: actually my previous edit is now more of an open question... what do we want the path to be?

To this end, we move these crates to their own directory at the top level of the repo. ./x.py and other tools and documentation are updated to use the new path. No semantic/API changes are proposed in this MCP.

A possible future direction (which this MCP is not proposing yet) might be to make cargo +beta build -p std work for building std instead of ./x.py (which I'm told may already work). We would also want to make it easy to use and test artifacts built like this. Together with this MCP, such changes would make contributing to libstd much more like a normal crate, reducing a major barrier to contributors. But this MCP still claims to be an improvement in the absence of these hypothetical changes.

Mentors or Reviewers

Who will review this work? If you are being mentored by someone, then list
their name here. If you are a compiler team member/contributor, and you
intend to mentor someone else, then you can put your own name here. You can
also leave it blank if you are looking for a reviewer. (Multiple names are ok
too.)

mentors: @Mark-Simulacrum
@mark-i-m mark-i-m added T-compiler Add this label so rfcbot knows to poll the compiler team major-change A proposal to make a major change to rustc labels May 29, 2020
@rustbot rustbot added the to-announce Announce this issue on triage meeting label May 29, 2020
@Mark-Simulacrum
Copy link
Member

@rustbot seconded

I'm on board with this change - I'm not 100% certain that std is the best top-level directory, but I think we can continue discussing that as we go to land it.

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label May 29, 2020
@sfackler
Copy link
Member

SGTM, but while we're at it, it'd be great to finally fix the directory layout of the crates so there's actually a src directory rather than all of the files sitting next to Cargo.toml.

@nikomatsakis
Copy link
Contributor

interesting idea

@spastorino spastorino added major-change-accepted A major change proposal that was accepted and removed to-announce Announce this issue on triage meeting labels Jun 3, 2020
@spastorino spastorino removed the final-comment-period The FCP has started, most (if not all) team members are in agreement label Jun 11, 2020
@mark-i-m mark-i-m mentioned this issue Jun 12, 2020
Merged
@mark-i-m mark-i-m mentioned this issue Jun 20, 2020
Closed
3 tasks
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 27, 2020
@bors
Auto merge of rust-lang#73265 - mark-i-m:mv-std, r=<try>
54e0008 
mv std libs to library/

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 the `src/` 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 the `lib*` prefixes and add nested `src/` directories.  The other crates/tools in this repo are not touched. So in summary:

```
library/<crate>/src/*.rs
src/<all the rest>     // unchanged
```

where `<crate>` is:
- core
- alloc
- std
- test
- proc_macro
- panic_abort
- panic_unwind
- profiler_builtins
- term
- unwind
- rtstartup
- backtrace
- rustc-std-workspace-*

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: rust-lang#73265 (comment).

The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree, e.g., through GitHub's UI or `cd`), 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 nested `src/` than against.

After this PR, there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 28, 2020
@bors
Auto merge of rust-lang#73265 - mark-i-m:mv-std, r=Mark-Simulacrum,ma…
ac48e62 
…rk-i-m

mv std libs to library/

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 the `src/` 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 the `lib*` prefixes and add nested `src/` directories.  The other crates/tools in this repo are not touched. So in summary:

```
library/<crate>/src/*.rs
src/<all the rest>     // unchanged
```

where `<crate>` is:
- core
- alloc
- std
- test
- proc_macro
- panic_abort
- panic_unwind
- profiler_builtins
- term
- unwind
- rtstartup
- backtrace
- rustc-std-workspace-*

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: rust-lang#73265 (comment).

The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree, e.g., through GitHub's UI or `cd`), 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 nested `src/` than against.

After this PR, there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).
@mark-i-m mark-i-m mentioned this issue Jul 28, 2020
Closed
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@spastorino @nikomatsakis @sfackler @Mark-Simulacrum @mark-i-m @rustbot