Handle non-existent upstream master branches in `x fmt`
People who do have a remote for `rust-lang/rust` but don't have the master branch checked out there used to get this error when running `x fmt`:
> fatal: ambiguous argument 'rust/master': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git <command> [<revision>...] -- [<file>...]'
> rust/master
Which is not exactly helpful.
Now, we fall back to `origin/master` (hoping that at least that remote exists) for that case. If there is still some error, we just fall back to `x fmt .` and print a warning.
r? `@jyn514`
Historically, Rust's Fuchsia targets have been labeled x86_64-fuchsia
and aarch64-fuchsia. However, they should technically contain vendor
information. This CL changes Fuchsia's target triples to include the
"unknown" vendor since Clang now does normalization and handles all
triple spellings.
This was previously attempted in #90510, which was closed due to
inactivity.
Allow passing a specific date to `bump-stage0`
This allows regenerating `src/stage0.json` on changes to the tool, without needing to hard-code the date in the source. It was useful for https://github.com/rust-lang/rust/pull/106394, which added clippy to the list of required components.
r? `@pietroalbini`
Ensure `lld` is supported with `download-ci-llvm`
This PR:
- ensures LLD's step in bootstrap's dist, but it's not strictly necessary since dist will already package it when it's present.
- makes bootstrap's `native::LLD` step support using the packaged `ci-llvm/bin/lld`, instead of building it from source (which would most likely not be available today, nor in the future where `download-ci-llvm = if-available` is the default).
If I understand correctly, `--enable-full-tools` will also enable `rust.lld`, and this is why LLD is already packaged today in the `rust-dev` component on the main targets (and why `-Zgcc-ld=lld` does work there).
That means it's likely that this PR will not be able to land before I've reworked and landed #101792: if LLD is available in `download-ci-llvm`, the `needs-rust-lld` tests should start being executed on the x64 macOS test builders, and CI would fail today.
I've tested locally that building with `download-ci-llvm = true` and `lld = true` with the LLVM submodule unregistered was successful, and that `rust-lld` and the various `lld-wrapper`s are present and `-Zgcc-ld=lld` works as well, on a few different platforms:
- `x86_64-unknown-linux-gnu`
- `aarch64-apple-darwin`
- `x86_64-pc-windows-msvc` (with `-Clinker=rust-lld` rather than `-Zgcc-ld=lld`)
- `x86_64-apple-darwin`, with the `MACOSX_DEPLOYMENT_TARGET` workaround for #101653
I don't think we really need to bump the `download-ci-llvm-stamp` in this case, since `./build/$triple/ci-llvm/bin/lld` is present on all the above targets already, but have added it mechanically, and it should probably be removed to avoid unnecessary downloads/churn.
Fixes#98340
Supersedes #100010
warn newer available version of the x tool
This PR adds a check to `tidy` to assert that the installed version of `x` is equal to the version in `src/tools/x/Cargo.toml`. It adds a `--wrapper-version` argument to `x` to determine the version at runtime, .
It does not warn if `x` has not yet been installed, on the assumption that the user isn't interested in using it.
Only include metadata for non-dynamic libraries in rustc-dev
The actual object code should be linked from librustc_driver.so, which is still included in rustc-dev. This saves on download time and disk usage.
Fixes https://github.com/rust-lang/rust/issues/103538
Dont use `--merge-base` during bootstrap formatting subcommand
I use a development image with Ubuntu 20.04 LTS, which has git 2.25.
Recently, `./x.py test tidy --bless` regressed in #105702 because it uses the `--merge-base` option on `diff-index`, which was only introduced in git 2.30 (git/git@0f5a1d449b). Luckily, it can be replicated via two calls to `git merge-base` + `git diff-index`, so let's just use that.
Before:
```
Testing ["rustc_interface"] stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
```
After:
```
Testing {rustc_interface} stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
```
Note there is a slight consistency between `build` and `test`: The
former doesn't print "compiler artifacts". It would be annoying to fix
and doesn't hurt anything, so I left it be.
```
; x t rustc_interface --stage 0 --dry-run
Testing {rustc_interface} stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
; x b rustc_interface --stage 0 --dry-run
Building {rustc_interface} stage0 compiler artifacts (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
```
Respect --set=target.platform when building rustbuild itself
`--set=target.platform.cc` and `--set=target.platform.cxx` are ignored if target is quoted.
`--set=target.platform.linker` is ignored if RUSTFLAGS is not set.
Undo parts of
d1291dc8b4 and
1532fd8cd0
Previously, clean only supported `--stage 0` for specific crates.
The new `crate_description` function generates a string that looks
like
```
: {rustc_query_impl}
```
Avoid quoting targets that do not contain a period.
See 1532fd8cd0
`--set=target.platform.linker` is ignored if RUSTFLAGS is not set.
Undo parts of d1291dc8b4
Bump master bootstrap compiler
This PR bumps the bootstrap compiler to the beta created earlier this week, cherry-picks the stabilization version number updates, and updates the `cfg(bootstrap)`s.
r? `@Mark-Simulacrum`
Allow cleaning individual crates
As a bonus, this stops special casing `clean` in `Builder`.
## Motivation
Cleaning artifacts isn't strictly necessary to get cargo to rebuild; `touch compiler/rustc_driver/src/lib.rs` (for example) will also work. There's two reasons I thought making this part of bootstrap proper was a better approach:
1. `touch` does not *remove* artifacts, it just causes a rebuild. This is unhelpful for when you want to measure how long the compiler itself takes to build (e.g. for https://github.com/rust-lang/rust/issues/65031).
2. It seems a little more discoverable; and I want to extend it in the future to things like `x clean --stage 1 rustc`, which makes it easier to work around https://github.com/rust-lang/rust/issues/76720 without having to completely wipe all the stage 0 artifacts, or having to be intimately familiar with which directories to remove.
Improve top-level docs
See a detailed explanation in the commit messages. This is a companion PR to https://github.com/rust-lang/rustc-dev-guide/pull/1528.
* Link to other resources instead of inlining their information
* Remove ancient and outdated reference to `config.mk`
* Suggest `profile = "user"` in the README
* Add detail about dependencies from the dev-guide
* Link to CONTRIBUTING.md instead of rustc-dev-guide in the main readme
* Link to `std-dev-guide` in CONTRIBUTING.md
