Update cargo submodule
13 commits in 2d4fa139552ebdd5f091a1401ed03f7dc62cb43f..5c0343317ce45d2ec17ecf41eaa473a02d73e29c
2025-11-12 15:56:06 +0000 to 2025-11-18 19:05:44 +0000
- feat: emit a warning when both `package.publish` and `--index` are specified (rust-lang/cargo#16268)
- docs(cargo-yank): clarify yank behavior with leaked credentials (rust-lang/cargo#16274)
- feat(generate-lockfile): Add unstable --publish-time flag (rust-lang/cargo#16265)
- Do not lock the artifact-dir for check builds (rust-lang/cargo#16230)
- fix(fingerprint): force update mtime of cargo-check artifacts (rust-lang/cargo#16262)
- fix(manifest): Point out when a key belongs to config (rust-lang/cargo#16256)
- Use raw false during cfg test (rust-lang/cargo#16261)
- Suppress metadata warnings for non–crates.io publishable packages (rust-lang/cargo#16241)
- feat(tree): Support long forms for --format variables (rust-lang/cargo#16204)
- fix(config): Fallback to non-canonical path for workspace-path-hash (rust-lang/cargo#16248)
- fix: update mtime for generated files after unpacking (rust-lang/cargo#16250)
- feat(cli): Add support for completing `--config` values in Bash (rust-lang/cargo#16245)
- feat: Add a typos CI job (rust-lang/cargo#16122)
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>
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#147171 (recommend using a HashMap if a HashSet's second generic parameter doesn't implement BuildHasher)
- rust-lang/rust#147421 (Add check if span is from macro expansion)
- rust-lang/rust#147521 (Make SIMD intrinsics available in `const`-contexts)
- rust-lang/rust#148201 (Start documenting autodiff activities)
- rust-lang/rust#148797 (feat: Add `bit_width` for unsigned `NonZero<T>`)
- rust-lang/rust#148798 (Match <OsString as Debug>::fmt to that of str)
- rust-lang/rust#149082 (autodiff: update formating, improve examples for the unstable-book)
r? `@ghost`
`@rustbot` modify labels: rollup
feat: Add `bit_width` for unsigned `NonZero<T>`
- Tracking issue: rust-lang/rust#142326
This pull request adds a method to the unsigned `NonZero<T>` that return the minimum number of bits required to represent a value.
This can be achieved by using the `get` method and the methods added in rust-lang/rust#142328, but I think adding the `NonZero::bit_width` method is useful because it accomplishes the same thing a little more succinctly.
Make SIMD intrinsics available in `const`-contexts
successor to rust-lang/rust#146568, this PR actually makes the SIMD intrinsics `const`, and modifies the tests to test the const-eval implementations
r? `@tgross35` ig (although feel free to reassign, this is not anything targeted really)
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.
Update wasm-related dependencies in CI
* Update to wasi-sdk-29 released today
* Update to Wasmtime 38.0.4 which was released a week or so ago
This is the same as rust-lang/rust#148611, except with wasi-sdk-29 to fixup some issues found in wasi-sdk-28.
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.)
Improve the documentation of atomic::fence
Attempt to "fix" two flaws of the current documentation:
1. The over-emphasis of fence - fence synchronization, relegating atomic - fence and fence - atomic synchronization to second fiddle.
2. The lack of explanation as to how to properly perform atomic - fence and fence - atomic synchronization.
It does so by first making it clear that there are 3 different ways to use an atomic fence, then presenting a full example for each usecase, noting the particular position of the fence with regard to the atomic operation, and rounding up with generic notes.
compiletest: Use JSON "binary-format" to decide `//@ only-elf` and `//@ ignore-elf`
Some tests only apply to ELF targets, or want to enable different test revisions for ELF and non-ELF targets. So compiletest supports the `//@ only-elf` and `//@ ignore-elf` directives to make that possible.
Historically, deciding whether the current target is an ELF target relied on a handful of ad-hoc string comparisons against the target tuple.
However, nowadays compiletest has access to the output of `--print=all-target-specs-json`, and that JSON output specifies the binary format of each target, making it much easier to determine whether a target is ELF or not.
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.
Replace OffsetOf by an actual sum of calls to intrinsic.
This PR changes the way we compute the value of the `offset_of!` macro in MIR. The current implementation uses a dedicated MIR rvalue.
This PR proposes to replace it by an inline constant which sums calls to a new intrinsic `offset_of(variant index, field index)`. The desugaring is done at THIR building time, easier that doing it on MIR.
The new intrinsic is only meant to be used by const-eval. LLVM codegen will refuse to generate code for it.
We replace:
```rust
a = offset_of!(T, Variant1.Field1.Variant2.Field2);
```
By:
```rust
a = const {constant#n};
{constant#n}: usize = {
_1 = offset_of::<T>(index of Variant1, index of Field1);
_2 = offset_of::<U>(index of Variant2, index of Field2); // Where T::Variant1::Field1 has type U
_0 = _1 + _2
}
```
The second commit modifies intrinsic const checking to take `allow_internal_unstable` into account. The new intrinsic should only be called from stable `offset_of!` macro. The intrinsic itself is unstable, const-unstable, but `rustc_intrinsic_const_stable_indirect`.
Fixesrust-lang/rust#123959Fixesrust-lang/rust#125680Fixesrust-lang/rust#129425Fixesrust-lang/rust#136175
r? `@ghost`
Build with -Zannotate-moves by default (non-stage-0 only)
Build rustc and tools with -Zannotate-moves by default, both to exercise the feature and because could be useful for doing performance measurement on rustc and its tools. This has no effect on generated code, it just adds extra debug info in
the form of some new inlined functions.
This also adds bootstrap.toml config options
```
# rust.annotate-moves = true
# rust.annotate-moves-size-limit = 65
```
to allow this to be controlled locally.
This is only added for stage 1 and later. Stage 0 (the bootstrap compiler) doesn't yet support -Zannotate-moves.
