Target: Add mips mti baremetal support
Do the same thing as gcc, which use the vendor `mti` to mark the toolchain as MIPS32r2 default.
We support both big endian and little endian flavor:
mips-mti-none-elf
mipsel-mti-none-elf
Add UWP (msvc) target support page
- Added Platform Support page for `x86_64-uwp-windows-msvc`, `i686-uwp-windows-msvc`, `thumbv7a-uwp-windows-msvc` and `aarch64-uwp-windows-msvc`
- Adding myself as a maintainer
- Removing the ticks for `thumbv7a-pc-windows-msvc` and `thumbv7a-uwp-windows-msvc` as they do not currently build due to #134565 and https://github.com/rust-lang/backtrace-rs/pull/685
- Fixed a few minor issues to let most of the UWP targets compile
- Happy new year to all!
r? jieyouxu
deny usage of special FileCheck prefixes as revision names
Adds a check that ensures special FileCheck prefixes are not used as revision names.
Fix#130982
bootstrap: correctly handle doc paths within submodules
Fixes#135041 by passing the correct submodule path when requiring submodules. This PR changes `is_path_in_submodule` to `submodule_path_of`. `submodule_path_of` returns the path of the containing submodule when given a path nested inside a submodule we handle, and `None` otherwise.
I tested this manually locally by unregistering the `src/tools/cargo` submodule, then running `./x doc src/tools/cargo/src/doc`. This command fails on master with
```
thread 'main' panicked at src/bootstrap/src/utils/helpers.rs:441:5:
std::fs::read_dir(dir) failed with No such file or directory (os error 2)
```
since the require submodule fails as `src/tools/cargo/src/doc` is not a known submodule. Now we use the submodule path if such a nested-in-submodule-path is passed, and thus running this command with cargo submodule unregistered still succeeds:
```
Rustbook (x86_64-unknown-linux-gnu) - cargo
Doc path: /home/joe/repos/rust/build/x86_64-unknown-linux-gnu/doc/cargo/index.html
Build completed successfully in 0:00:11
```
r? `@onur-ozkan`
std: sync to dep versions of backtrace
Minor versions from backtrace desynced with std (they still differs in patch numbers, but still better):
4d7906bb24/Cargo.toml (L44-L48)
There is hidden bug here, let's see if CI can find it.
cc `@workingjubilee`
turn rustc_box into an intrinsic
I am not entirely sure why this was made a special magic attribute, but an intrinsic seems like a more natural way to add magic expressions to the language.
rustc_intrinsic: support functions without body
We synthesize a HIR body `loop {}` but such bodyless intrinsics.
Most of the diff is due to turning `ItemKind::Fn` into a brace (named-field) enum variant, because it carries a `bool`-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake `loop {}` body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden.
I first tried actually having no body rather than generating the fake body, but there's a *lot* of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even `rustc_intrinsic_must_be_overridden` intrinsics have MIR generated (they are filled with an `Unreachable` terminator) so I guess I am not the first to discover this. ;)
r? `@oli-obk`
Allow using self-contained LLD in bootstrap
In https://github.com/rust-lang/rust/pull/116278, I added a `"self-contained"` mode to the `rust.use-lld` bootstrap option, which was designed for using the built-in LLD for linking compiler artifacts. However, this was later reverted in https://github.com/rust-lang/rust/pull/118810.
This PR brings the old logic back, which switches LLD in bootstrap from `-fuse-ld=lld` to [MCP510](https://github.com/rust-lang/compiler-team/issues/510)'s way of passing linker flags to enable LLD (both external and self-contained). So this does two changes:
1) Goes from `-fuse-ld=lld` to MCP510
2) Actually makes it possible to use the self-contained LLD to compile compiler artifacts
Regarding the second commit: Since https://github.com/rust-lang/rust/pull/86113, we have been passing `-fuse-ld=lld` as a target flag to all tests when `use-lld = true` is enabled. This kind of worked for all tests, since it was just a linker argument, which has bypassed any compiler checks, and probably resulted only in some warning if the given target linker didn't actually support LLD. However, after the first commit, some tests actually start failing with this approach:
```
error: linker flavor `gnu-lld-cc` is incompatible with the current target
|
= note: compatible flavors are: llbc, ptx
```
So the second commit removes the passing of LLD flags as target flags to tests. I don't think that it's a good idea to pass specific compiler flags to all tests unconditionally, tbh. The doctest command from #86113 doesn't go through compiletest anymore, and doctests should be quite a lot faster since https://github.com/rust-lang/rust/pull/126245 in general.
CC `@the8472`
If someone has a beefy machine, it would be nice to test whether this doesn't regress test execution speed. How to do that:
1) Enable `rust.use-lld = true` and `rust.lld = true` in `config.toml`
2) Benchmark `./x test tests/ui --force-rerun` between `master` and this PR
Once this is tested in the wild, I would like to make the self-contained LLD the default in CI, hopefully to make CI builds faster.
r? `@onur-ozkan`
refactor bootstrap path resolution
Previously we removed paths as soon as we found the first intersection, which made it impossible to find other intersecting paths (and that is the reason of https://github.com/rust-lang/rust/issues/135022).
This patch changes that by marking the intersecting paths instead, so we can collect them all and remove them together when needed. Which means, `x build compiler` would compile anything that ends or starts with `"compiler"` instead of picking the first matching `Step` from `builder::get_step_descriptions`.
Fixes https://github.com/rust-lang/rust/issues/135022
rustdoc: treat `allowed_through_unstable_modules` as deprecation
This ensures `std::intrinsics::transmute` is deemphasized in the search engine and other UI, by cleaning it into a deprecation without propagating it through reexports when the parent module is stable.
Fixes#131676
Related to #135003
r? ``@GuillaumeGomez``
``@RalfJung`` ``@workingjubilee``
run-make-support: adjust assertion printing, add some basic sanity checks
cc ``@Noratrieb``
I think we may have unintentionally regressed this recently and double-printed (or printed even when the assertions didn't fail). This PR should condition the detail dumps only when the assertions fail.
Added some basic sanity checks for the assertions helpers except for the directory comparisons. That particular helper is not robust against symlinks, and I intend to address it in a follow-up (issue is #135037).
r? bootstrap (or compiler)
Do the same thing as gcc, which use the vendor `mti` to mark
the toolchain as MIPS32r2 default.
We support both big endian and little endian flavor:
mips-mti-none-elf
mipsel-mti-none-elf
Previously we removed paths as soon as we found the first intersection, which made
it impossible to find other intersecting paths. This patch changes that by marking
the intersecting paths instead, so we can collect them all and remove them together
when needed.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
