Inherent const impl
Some constifications are annoying because we need to repeat `T: Trait` bounds from an impl block on the individual constified `const fn`s as `T: [const] Trait`. We've brainstormed solutions before, and one would be to have separate `const impl` blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.
Also interacts with the discussion around `impl const Trait for Type` vs `const impl Trait for Type`, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).
* [ ] rustdoc + tests
* [ ] macro stability /regression tests
r? `@fee1-dead`
cc `@traviscross` `@rust-lang/project-const-traits`
debug-assert FixedSizeEncoding invariant
Something like this? It asserts during encoding that for that type, decoding 0 would give the default.
Preferably, I'd either somehow statically/in const assert it once, instead of every time, but I see no easy way to do so. It'd require us to iterate all types that implement the trait or something. Let me know what you think
No types currently violate this invariant.
r? `@oli-obk`
repr(transparent) check: do not compute check_unsuited more than once
`field_infos` is an iterator that we execute multiple times. However, we usually ignore the `unsuited` field -- we only need it in the last iteration. So move the computation of that field to that iteration to avoid computing it multiple times. Computing `unsuited` involves a recursive traversal over the types of all non-trivial fields, so there can be non-trivial amounts of work here.
(I benchmarked this in https://github.com/rust-lang/rust/pull/148243 and saw no changes, probably because we don't have a benchmark with many repr(transparent) types. But still, computing this each time just seemed silly.)
flush_delayed: add note about stashed diagnostics
r? `@nnethercote`
Is `emit_stashed_diagnostics` the right advice to give? The other option seems to be to call `finish_diagnostics`. That's what I ended up doing (for now) in https://github.com/rust-lang/miri/pull/4702 because it best matches what happens during normal compilation.
Document the `let this = self;` idiom used in MIR building
In `rustc_mir_build` there are a few `Builder` methods that start with `let this = self;`, so that subsequent code can uniformly refer to the builder as `this`, instead of having to choose between `self` at the top level or `this` when nested in closures that need to borrow the builder.
There is some existing documentation of the idiom in `expr_into_dest`:
https://github.com/rust-lang/rust/blob/69d4d5fc0e4db60272aac85ef27ecccef5764f3a/compiler/rustc_mir_build/src/builder/expr/into.rs#L32-L35
But that documentation is brief and hard to find, especially if one is unaware that such documentation even exists.
---
This PR therefore adds a longer explanation of the `let this = self;` idiom in the module documentation for `rustc_mir_build::builder`, and makes that documentation easier to find by adding a searchable tag (“LET_THIS_SELF”) to the documentation and to each occurrence of the idiom.
Tweak Motor OS linker preset, fix `remote-test-server` for Motor OS
Had to tweak linking options in target spec to make it work (see https://github.com/moturus/motor-os/issues/46).
Error if an autodiff user does not set lto=fat
Based on your feedback, I started to provide a nice error message for a lack of `lto=fat`, instead of us forcing it.
In a next step, we should replace `RUSTFLAGS="-Zautodiff=Enable"` with another Cargo.toml setting, as discussed here: https://github.com/rust-lang/rust/issues/147487#issuecomment-3446558644
As another improvement, we should also figure out why rlib builds do not properly obey the fat=lto setting.
```````@bjorn3```````
use funnel shift as fallback impl for rotating shifts
That lets us remove this gnarly implementation from Miri and const-eval.
However, `rotate_left`/`rotate_right` are stable as const fn, so to do this we have to `rustc_allow_const_fn_unstable` a bunch of const trait stuff. Is that a bad idea? Cc `@oli-obk` `@fee1-dead`
Use rustc target metadata for build-manifest target lists
This ensures that as long as the target metadata is updated to reflect the current state (tier 3 vs 1/2, host toolchain support), the manifest will also be updated. This avoids an extremely common 'oops' when we move targets between tiers.
This mostly removes a bunch of tier 3 targets from manifests. I didn't spot check against produced artifacts but given that they are tier 3 it's probably reasonable to leave it as-is and bug reporters can fix the target metadata in rustc (or we can stop producing artifacts).
Follow-up work would ideally lint the artifact list as part of nightly/beta/stable builds as well, but for now this is simple and hopefully removes at common source of extra PRs when modifying targets.
Manifest list delta:
```diff
--- old
+++ new
-host:i686-apple-darwin
-host:mips-unknown-linux-gnu
-host:mips64-unknown-linux-gnuabi64
-host:mips64el-unknown-linux-gnuabi64
-host:mipsel-unknown-linux-gnu
-host:mipsisa32r6-unknown-linux-gnu
-host:mipsisa32r6el-unknown-linux-gnu
-host:mipsisa64r6-unknown-linux-gnuabi64
-host:mipsisa64r6el-unknown-linux-gnuabi64
-target:aarch64-unknown-hermit
-target:aarch64-unknown-managarm-mlibc
-target:aarch64-unknown-redox
-target:amdgcn-amd-amdhsa
-target:arm64e-apple-darwin
-target:arm64e-apple-ios
-target:arm64e-apple-tvos
-target:armebv7r-none-eabi
-target:armebv7r-none-eabihf
-target:armv7s-apple-ios
-target:bpfeb-unknown-none
-target:bpfel-unknown-none
-target:csky-unknown-linux-gnuabiv2
-target:csky-unknown-linux-gnuabiv2hf
-target:i386-apple-ios
-target:i586-unknown-redox
-target:i686-apple-darwin
-target:loongarch32-unknown-none
-target:loongarch32-unknown-none-softfloat
-target:m68k-unknown-linux-gnu
-target:m68k-unknown-none-elf
-target:mips-mti-none-elf
-target:mips-unknown-linux-gnu
-target:mips-unknown-linux-musl
-target:mips64-unknown-linux-gnuabi64
-target:mips64-unknown-linux-muslabi64
-target:mips64el-unknown-linux-gnuabi64
-target:mips64el-unknown-linux-muslabi64
-target:mipsel-mti-none-elf
-target:mipsel-unknown-linux-gnu
-target:mipsel-unknown-linux-musl
-target:mipsisa32r6-unknown-linux-gnu
-target:mipsisa32r6el-unknown-linux-gnu
-target:mipsisa64r6-unknown-linux-gnuabi64
-target:mipsisa64r6el-unknown-linux-gnuabi64
-target:riscv32gc-unknown-linux-gnu
-target:riscv32im-risc0-zkvm-elf
-target:riscv32ima-unknown-none-elf
-target:riscv64gc-unknown-hermit
-target:riscv64gc-unknown-linux-musl
-target:riscv64gc-unknown-managarm-mlibc
-target:sparc-unknown-none-elf
-target:x86_64-unikraft-linux-musl
-target:x86_64-unknown-hermit
-target:x86_64-unknown-managarm-mlibc
```
This ensures that as long as the target metadata is updated to reflect
the current state (tier 3 vs 1/2, host toolchain support), the manifest
will also be updated. This avoids an extremely common 'oops' when we
move targets between tiers.
This mostly removes a bunch of tier 3 targets from manifests. I didn't
spot check against produced artifacts but given that they are tier 3
it's probably reasonable to leave it as-is and bug reporters can fix the
target metadata in rustc (or we can stop producing artifacts).
Follow-up work would ideally lint the artifact list as part of
nightly/beta/stable builds as well, but for now this is simple and
hopefully removes at common source of extra PRs when modifying targets.
fix(span): track unnormalized source len for dep-info
Add `unnormalized_source_len` field to track the byte length
of source files before normalization (the original length).
`unnormalized_source_len` is for writing the correct file length
to dep-info for `-Zchecksum-hash-algorithm`
Fixes https://github.com/rust-lang/rust/issues/148934
Add `unnormalized_source_len` field to track the byte length
of source files before normalization (the original length).
`unnormalized_source_len` is for writing the correct file length
to dep-info for `-Zchecksum-hash-algorithm`
compute temporary scopes when building MIR, not THIR
This accomplishes two things:
- Makes the THIR slightly smaller by not attaching a full `TempLifetime` to every expression.
- Reduces the number of traversals of the `ScopeTree` by only calling `ScopeTree::temporary_scope` when building MIR for something that needs to be dropped in a temporary scope.
error when ABI does not support guaranteed tail calls
Some ABIs cannot support guaranteed tail calls. There isn't really an exhaustive list, so this is a best effort. Conveniently, we already disallow calling most of these directly anyway. The only exception that I was able to trigger an LLVM assertion with so far was `cmse-nonsecure-entry`.
For that calling convention, LLVM specifically notes that (guaranteed) tail calls cannot be supported:
https://github.com/llvm/llvm-project/blob/28dbbba6c3a4e026e085c48cc022cb97b5d8bc6d/llvm/lib/Target/ARM/ARMISelLowering.cpp#L2331-L2335
---
I have some doubts about the implementation here though. I think it would be nicer to use `CanonAbi`, and move the `become` ABI check into `rustc_hir_typeck`, similar to `check_call_abi`:
https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/callee.rs#L157-L194
Both the check for whether an ABI is callable and whether it supports guaranteed tail calls can then be methods (containing exhaustive matches) on `CanonAbi`. I'm however not sure
- if the ABI checks are deliberately only performed when constructing MIR
- what assumptions can be made about the `call` expression in [`check_expr_become`](https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/expr.rs#L1126-L1150), it looks like currently the check that the "argument" to `become` is a function call also only occurs later during MIR construction
Are there issues with validating the ABI earlier in `rustc_hir_typeck` that I'm overlooking? I believe that we should already know the call's ABI and whether it is c-variadic at that point.
cc ````@workingjubilee```` for `CanonAbi`, ````@davidtwco```` for cmse
r? ````@WaffleLapkin````
bors