MCP: Reorganize the rust-lang/rust repo directory structure

[mark-i-m]

Proposal

EDIT(mark-i-m): Updated as per feedback

In #298 (accepted), we decided to move the standard libraries into their own std/ directory at the root of the repo. In this proposal, we follow through to reorganize the compiler source into a new compiler/ directory:

- std/        // as in #298 
- compiler/
  - librustc_* -> rustc_*
  - rustc/ -> bin/rustc/
  - llvm-project (submodule)
  - test/ (only compiler tests)
- src/      // unchanged

The primary goals of this proposal are to

1. make it more obvious where things live by separating out distinct-ish parts of the project into different top-level directories
2. help (especially new) contributors to feel less overwhelmed by the size of the project by breaking the top-level directories down into more manageable and modular parts
3. work towards a world in which std/core and/or other parts of the project can be built independently of the compiler

Note that in particular, we move some things around:

• The src/test directory is split up to compiler/test and src/test/

Approval: We anticipate a lot of bikeshedding over names, exact paths, and etc. We propose to resolve disagreements so as to match whatever consensus is reached with respect to similar discussion on std/ (e.g. whether to have src/ directories). Moreover, the approval of this MCP will be construed as a green light to start working on PRs, but not as consensus on the exact final form. Rather, a separate FCP will be required to merge e.g. the PR that moves compiler/.

Followup: In followup MCPs similar to this one, we will move around other parts of src until we reach an acceptable state.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.

I suspect that a lot of help will be needed from different parts of the different teams. @Mark-Simulacrum mentored/seconded #298, but I don't know if they wish to mentor/second this MCP. @Dylan-DPC also expressed interest in working on this.

Process

The main points of the Major Change Process is as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

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.

[rustbot]

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.

[petrochenkov]

+1, but this involves too many teams and too much bikeshedding at the same time, starting with librustc_* crates would be more manageable.

[mark-i-m]

(moving to zulip thread)