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
Searching "fma" in the Rust documentation returns results for
`intrinsics::fma*`, but does not point to the user-facing `mul_add`. Add
aliases for `fma*` and the IEEE operation name `fusedMultiplyAdd`. Add
the IEEE name to `sqrt` as well, `squareRoot`.
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
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.
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`
