Add support for riscv64gc-unknown-freebsd
For https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy:
* A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
For all Rust targets on FreeBSD, it's [rust@FreeBSD.org](mailto:rust@FreeBSD.org).
* Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
Done.
* Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
Done
* Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
Done.
* The target must not introduce license incompatibilities.
Done.
* Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Fine with me.
* The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
Done.
* If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
Done.
* Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
Done.
* "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
Fine with me.
* Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Ok.
* This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
Ok.
* Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
std is implemented.
* The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.
Building is possible the same way as other Rust on FreeBSD targets.
* Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Ok.
* Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
Ok.
* Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Ok.
* In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
Ok.
Previously, it would concatenate the relative path to the current
subdirectory, which looked at the wrong folder.
I tested this by checking out `1.56.1`, changing the current directory
to `src/`, and running `../x.py build`.
bootstap: create .cargo/config only if not present
In some situations we should want on influence into the .cargo/config
when we use vendored source. One example is #90764, when we want to
workaround some references to crates forked and living in git, that are
missing in the vendor/ directory.
This commit will create the .cargo/config file only when the .cargo/
directory needs to be created.
std: Get the standard library compiling for wasm64
This commit goes through and updates various `#[cfg]` as appropriate to
get the wasm64-unknown-unknown target behaving similarly to the
wasm32-unknown-unknown target. Most of this is just updating various
conditions for `target_arch = "wasm32"` to also account for `target_arch
= "wasm64"` where appropriate. This commit also lists `wasm64` as an
allow-listed architecture to not have the `restricted_std` feature
enabled, enabling experimentation with `-Z build-std` externally.
The main goal of this commit is to enable playing around with
`wasm64-unknown-unknown` externally via `-Z build-std` in a way that's
similar to the `wasm32-unknown-unknown` target. These targets are
effectively the same and only differ in their pointer size, but wasm64
is much newer and has much less ecosystem/library support so it'll still
take time to get wasm64 fully-fledged.
In some situations we should want on influence into the .cargo/config
when we use vendored source. One example is #90764, when we want to
workaround some references to crates forked and living in git, that are
missing in the vendor/ directory.
This commit will create the .cargo/config file only when the .cargo/
directory needs to be created.
Before, you could have the confusing situation where the command to
generate a component had no relation to the name of that component (e.g.
the `rustc` component was generated with `src/librustc`). This changes
the name to make them match up.
* Add wasm64 variants for inline assembly along the same lines as wasm32
* Update a few directives in libtest to check for `target_family`
instead of `target_arch`
* Update some rustc codegen and typechecks specialized for wasm32 to
also work for wasm64.
Document clippy on nightly-rustc
Adding Clippy's docs to nightly-rustc, based on commit 01cf0bde. This PR only adds `clippy_utils` to the documentation. I've decided to only document one crate for now, as `clippy_lints` etc. contain very specific and undocumented functions which aren't really reusable. I'm guessing that they would mostly clutter up the search results with little benefit.
`./x.py --stage 1 doc src/tools/clippy` if working fine now after the help that ```````@jyn514``````` and ```````@ehuss``````` have provided. A big THANK YOU to them!
Handling submodule update failures more gracefully from x.py
Addresses #80498
Handling the case where x.py can't check out the right commit of a submodule, because the submodule has local edits that would be overwritten by the checkout, more gracefully.
The error is printed in detail, with some hints on how to revert the local changes to the submodule.
Update the minimum external LLVM to 12
With this change, we'll have stable support for LLVM 12 and 13.
For reference, the previous increase to LLVM 10 was #83387,
and this replaces the pending increase to LLVM 11 in #90062.
r? `@nagisa` `@nikic`
Make new symbol mangling scheme default for compiler itself.
As suggest in https://github.com/rust-lang/rust/pull/89917#issuecomment-945888574, this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet).
r? `@Mark-Simulacrum`
I'm working on some LLVM patches in concert with a Rust patch, and it's
helping me quite a bit to have this as an option. It doesn't seem that
hard, so I figured I'd formalize it in x.py and send it upstream.
bootstrap: tweak verbosity settings
Currently the verbosity settings are:
- 2: RUSTC-SHIM envvars get spammed on every invocation, O(30) lines
cargo is passed -v which outputs CLI invocations, O(5) lines
- 3: cargo is passed -vv which outputs build script output, O(0-10) lines
This commit changes it to:
- 1: cargo is passed -v, O(5) lines
- 2: cargo is passed -vv, O(10) lines
- 3: RUSTC-SHIM envvars get spammed, O(30) lines
Make `llvm.download-ci-llvm="if-available"` work for tier 2 targets with host tools
`llvm.download-ci-llvm="if-available"` is used for most profiles configured via `x.py setup`. It allows downloading prebuilt LLVM tarballs from the CI artifacts for a configured list of platforms. Currently this list is restricted to tier 1 targets but it makes sense for all tier 2 targets with host tools.
Currently the verbosity settings are:
- 2: RUSTC-SHIM envvars get spammed on every invocation, O(30) lines
cargo is passed -v which outputs CLI invocations, O(5) lines
- 3: cargo is passed -vv which outputs build script output, O(0-10) lines
This commit changes it to:
- 1: cargo is passed -v, O(5) lines
- 2: cargo is passed -vv, O(10) lines
- 3: RUSTC-SHIM envvars get spammed, O(30) lines
Allow static linking LLVM with ThinLTO
There's no reason not to allow this if the user wants it. It works, at least in a local build on linux host.
For our use case, we're happy to spend more time building the compiler if it creates a speedup every time we run it, and we've observed speedups like this with clang.
Assemble the compiler when running `x.py build`
Previously, there was no way to actually get binaries in
`build/$TARGET/stage1/bin` without building the standard library. This
makes it possible to build just the compiler. This can be useful when
the standard library isn't actually necessary for trying out your tests
(e.g. a bug that can be reproduced with only a `no_core` crate).
Closes https://github.com/rust-lang/rust/issues/73519.
Use shallow clones for submodules
This reduces the amount of git history downloaded for submodules from ~67M to ~11M. For comparison, a shallow clone of rust-lang/rust is 103M and a deep clone is 740M, so this almost halves the amount of history necessary if you made a shallow clone to start, and it's a significant reduction even if not.
Closes https://github.com/rust-lang/rust/issues/63978. r? `@Mark-Simulacrum`
Previously, there was no way to actually get binaries in
`build/$TARGET/stage1/bin` without building the standard library. This
makes it possible to build just the compiler. This can be useful when
the standard library isn't actually necessary for trying out your tests
(e.g. a bug that can be reproduced with only a `no_core` crate).
Remove hack ignoring unused attributes for stage 0 std
This seems to no longer be giving spurious errors when incremental is
enabled.
Closes https://github.com/rust-lang/rust/issues/58633.
bootstrap: don't use `--merges` to look for commit hashes for downloading artifacts
Shallow clones (and possibly worktrees, though I can't seem to reproduce the problem there) can cause `git rev-list --merges` to falsely return no results, even if a merge commit is present. Stop using the `--merges` option when looking for commit hashes that have build artifacts. `--first-parent` and `--author=bors@rust-lang.org` should be sufficient.
Also exit with an error if the configuration asks for artifacts to be downloaded and we can't determine an appropriate commit hash to use to download artifacts.
Fixes#87890.
r? ``@jyn514``
``@rustbot`` label +A-rustbuild +A-contributor-roadblock
Rather than compiling rustbuild and all its dependencies with
`debuginfo=2`, this compiles dependencies without debuginfo and
rustbuild with `debuginfo=1`. On my laptop, this brings compile times
down from ~1:20 to ~1:05.
Don't rebuild GUI test crates every time you run test src/test/rustdoc-gui
This method has multiple advantages:
* It'll completely remove the rustdoc-GUI test doc folder if rustdoc was updated
* It'll rebuild GUI test crates only they have been updated
All in all, it's quite convenient! (even more with https://github.com/rust-lang/rust/pull/88816)
r? ```@Mark-Simulacrum```
