Rust's current mangling scheme depends on compiler internals; loses
information about generic parameters (and other things) which makes for
a worse experience when using external tools that need to interact with
Rust symbol names; is inconsistent; and can contain `.` characters
which aren't universally supported. Therefore, Rust has defined its own
symbol mangling scheme which is defined in terms of the Rust language,
not the compiler implementation; encodes information about generic
parameters in a reversible way; has a consistent definition; and
generates symbols that only use the characters `A-Z`, `a-z`, `0-9`, and
`_`.
Support for the new Rust symbol mangling scheme has been added to
upstream tools that will need to interact with Rust symbols (e.g.
debuggers).
This commit changes the default symbol mangling scheme from the legacy
scheme to the new Rust mangling scheme.
Signed-off-by: David Wood <david.wood@huawei.com>
Add check if span is from macro expansion
The same thing I did in https://github.com/rust-lang/rust/pull/147416, actually the same bug but in another place, I'm not really sure how this method is good for fixing such ICEs, but, it does work and not conflicting with any existing tests, so I guess, it's fine
Fixes https://github.com/rust-lang/rust/issues/147408
r? compiler
recommend using a HashMap if a HashSet's second generic parameter doesn't implement BuildHasher
closesrust-lang/rust#147147
~The suggestion span is wrong, but I'm not sure how to find the right one.~ fixed
I'm relatively new to the diagnostics ecosystem, so I'm not sure if `span_help` is the right choice. `span_suggestion_*` might be better, but the output from `x test` looks weird in that case.
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.
Matthias Krüger