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
do not in-place-iterate over flatmap/flatten
The implementation is unsound when a partially consumed iterator has some elements buffered in the front/back parts and cloning the Iterator removes the capacity from the backing vec::IntoIter.
This is a fix for #135103 that removes the specialization trait impls without removing some supporting parts. I've kept it small so it can be easily backported. I'll either remove the remaining parts or think of a way to recover the optimization in a separate PR.
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
Fixes
```
Checking stage0 library artifacts {alloc, core, panic_abort, panic_unwind, proc_macro, std, sysroot, test, unwind} (x86_64-unknown-linux-gnu)
warning: profile package spec `adler` in profile `release` did not match any packages
Did you mean `adler2`?
```
[Debuginfo] Force enum `DISCR_*` to `static const u64` to allow for inspection via LLDB
see [here](https://rust-lang.zulipchat.com/#narrow/channel/317568-t-compiler.2Fwg-debugging/topic/Revamping.20Debuginfo/near/486614878) for more info.
This change mainly helps `*-msvc` debugged with LLDB. Currently, LLDB cannot inspect `static` struct fields, so the intended visualization for enums is only borderline functional, and niche enums with ranges of discriminant cannot be determined at all .
LLDB *can* inspect `static const` values (though for whatever reason, non-enum/non-u64 consts don't work).
This change adds the `LLVMRustDIBuilderCreateQualifiedType` to the rust FFI layer to wrap the discr type with a `const` modifier, as well as forcing all generated integer enum `DISCR_*` values to be u64's. Those values will only ever be used by debugger visualizers anyway, so it shouldn't be a huge deal, but I left a fixme comment for it just in case.. The `tag` also still properly reflects the discriminant type, so no information is lost.
The implementation is unsound when a partially consumed iterator has
some elements buffered in the front/back parts and cloning the Iterator
removes the capacity from the backing vec::IntoIter.
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`
Bump backtrace to 0.3.75
I prefer when we can ship the same version of backtrace on crates.io, and this will be the next published version.
Compare: https://github.com/rust-lang/backtrace-rs/compare/4d7906b...0.3.75
Mostly internal-to-backtrace changes, plus a tiny code size win.
r? `@ghost`
Force code generation in assembly generation smoke-tests
In llvm/llvm-project@7b23f413d1 , `.text` started being suppressed from LLVM assembly in cases where it wasn't strictly necessary. Currently, the sample functions in these two tests are frequently decided to be IR-only functions, resulting in no code generation, so LLVM drops the `.text` directive.
Adding `#[no_mangle]` forces these tests back to their original intent - assembly code is generated, and so a `.text` directive is generated as well.
`@rustbot` label: +llvm-main
r? `@workingjubilee`
I'll attach a buildbot link once it finishes consuming this PR
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.
Pass the arch rather than full target name to windows_registry::find_tool
The full target name can be anything with custom target specs. Passing just the arch wasn't possible before cc 1.2, but is now thanks to https://github.com/rust-lang/cc-rs/pull/1285.
try-job: i686-msvc
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`
Rollup of 7 pull requests
Successful merges:
- #133964 (core: implement `bool::select_unpredictable`)
- #135001 (Allow using self-contained LLD in bootstrap)
- #135055 (Report impl method has stricter requirements even when RPITIT inference gets in the way)
- #135064 (const-in-pattern: test that the PartialEq impl does not need to be const)
- #135066 (bootstrap: support `./x check run-make-support`)
- #135069 (remove unused function params)
- #135084 (Update carrying_mul_add test to tolerate `nuw`)
r? `@ghost`
`@rustbot` modify labels: rollup
Update carrying_mul_add test to tolerate `nuw`
LLVM 20 adds nuw to GEP operations in this code, tolerate them.
`@rustbot` label: +llvm-main
r? `@durin42`
const-in-pattern: test that the PartialEq impl does not need to be const
Fixes https://github.com/rust-lang/rust/issues/119398 by adding a test.
`@compiler-errors` is there some place in the code where we could add a comment saying "as a backcompat hack, here we only require `PartialEq` and not `const PartialEq`"?
r? `@compiler-errors`
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`
Project to `TyKind::Error` when there are unconstrained non-lifetime (ty/const) impl params
It splits the `enforce_impl_params_are_constrained` function into lifetime/non-lifetime, and queryfies the latter. We can then use the result of the latter query (`Result<(), ErrorGuaranteed>`) to intercept projection and constrain the projected type to `TyKind::Error`, which ensures that we leak no ty or const vars to places that don't expect them, like `normalize_erasing_regions`.
The reason we split `enforce_impl_params_are_constrained` into two parts is because we only error for *lifetimes* if the lifetime ends up showing up in any of the associated types of the impl (e.g. we allow `impl<'a> Foo { type Assoc = (); }`). However, in order to compute the `type_of` query for the anonymous associated type of an RPITIT, we need to do trait solving (in `query collect_return_position_impl_trait_in_trait_tys`). That would induce cycles. Luckily, it turns out for lifetimes we don't even care about if they're unconstrained, since they're erased in all contexts that we are trying to fix ICEs. So it's sufficient to keep this check separated out of the query.
I think this is a bit less invasive of an approach compared to #127973. The major difference between this PR and that PR is that we queryify the check instead of merging it into the `explicit_predicates_of` query, and we use the result to taint just projection goals, rather than trait goals too. This doesn't require a lot of new tracking in `ItemCtxt` and `GenericPredicates`, and it also seems to not require any other changes to typeck like that PR did.
Fixes#123141Fixes#125874Fixes#126942Fixes#127804Fixes#130967
r? oli-obk
In llvm/llvm-project@7b23f413d1 , `.text`
started being suppressed from LLVM assembly in cases where it wasn't
strictly necessary. Currently, the sample functions in these two tests
are frequently decided to be IR-only functions, resulting in no code
generation, so LLVM drops the `.text` directive.
Adding `#[no_mangle]` forces these tests back to their original intent -
assembly code is generated, and so a `.text` directive is generated as
well.
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
Improve infer (`_`) suggestions in `const`s and `static`s
Fixes https://github.com/rust-lang/rust/issues/135010.
This PR does a few things to (imo) greatly improve the error message when users write something like `static FOO: [i32; _] = [1, 2, 3]`.
Firstly, it adapts the recovery code for when we encounter `_` in a const/static to work a bit more like `fn foo() -> _`, and removes the somewhat redundant query `diagnostic_only_typeck`.
Secondly, it changes the lowering for `[T; _]` to always lower under the `feature(generic_arg_infer)` logic to `ConstArgKind::Infer`. We still issue the feature error, so it's not doing anything *observable* on the good path, but it does mean that we no longer erroneously interpret `[T; _]`'s array length as a `_` **wildcard expression** (à la destructuring assignment, like `(_, y) = expr`).
Lastly it makes the suggestions verbose and fixes (well, suppresses) a bug with stashing and suggestions.
r? oli-obk
bjorn3