Add src/tools/x to the main workspace

[cuviper]

The original reason to exclude it was so it could run before submodules
were initialized. However, those have all been converted to subtrees
now, so the entire workspace is always ready to go.

I've also alphabetized the workspace members, as it was an untidy mess. 🧹

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

src/tools/x was changed. Bump version of Cargo.toml in src/tools/x so tidy will suggest installing the new version.

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[cuviper]

BTW, I think we could also do this for src/bootstrap, except it has some dependency version-pinning that we probably don't want to force on the entire workspace.

src/tools/x was changed. Bump version of Cargo.toml in src/tools/x so tidy will suggest installing the new version.

There's no meaningful change in the tool itself.

[jieyouxu]

Isn't cargo still a submodule, or does that not matter?

[cuviper]

It is, but it doesn't matter because it's in an independent workspace.

[cuviper]

Why on earth are the settings hashed into a test?!?

[jyn514]

because knowing when the settings change allows us to suggest re-running x setup editor

[bors]

☔ The latest upstream changes (presumably #138448) made this pull request unmergeable. Please resolve the merge conflicts.

[cuviper]

The conflict was just the removal of src/tools/rls, which my alphabetization tried to reorder.

[jieyouxu]

I'll test this on a fresh clone w/ no submodules initialized.
r? jieyouxu

[jieyouxu]

The changes themselves look good. Should we add a WARN-level change tracker entry, because people would need to adjust their r-a settings, right? EDIT: nvm, the hash differences will let people know, duh.

[jieyouxu]

For the changes themselves, I did some local testing:

Local testing

I performed a clone of this repo with explicitly cleared git configs (that should not recursively checkout submodules by default).

$ GIT_CONFIG_SYSTEM='' GIT_CONFIG_GLOBAL='' git clone https://github.com/rust-lang/rust.git rust-138179
$ GIT_CONFIG_SYSTEM='' GIT_CONFIG_GLOBAL='' git fetch origin pull/138179/head:pr-138179
$ GIT_CONFIG_SYSTEM='' GIT_CONFIG_GLOBAL='' git checkout pr-138179

With no bootstrap config.toml, I ran:

$ GIT_CONFIG_SYSTEM='' GIT_CONFIG_GLOBAL='' ./x build library --stage=1

I can confirm ./x binary can be built, and that I can further successfully bootstrap a stage 1 compiler and std.

I also redid the fresh clone then tried to run tidy:

$ GIT_CONFIG_SYSTEM='' GIT_CONFIG_GLOBAL='' ./x test tidy

I confirm that I can run tidy checks locally without any submodules being checkout out prior to this invocation, and that tidy completes successfully.

After redoing the clone and an explicit

$ GIT_CONFIG_SYSTEM='' GIT_CONFIG_GLOBAL='' git submodule deinit -f --all

I tried a basic dist flow

$ GIT_CONFIG_SYSTEM='' GIT_CONFIG_GLOBAL='' ./x dist rustc --stage=2

And while I didn't bother waiting it to finish, it got past the stage that would've failed if src/tools/x setup was completely broken.

[jieyouxu]

Thanks for the cleanup!
@bors r+ rollup

[bors]

📌 Commit 496788a has been approved by jieyouxu

It is now in the queue for this repository.