Update cargo submodule
14 commits in cbb9bb8bd0fb272b1be0d63a010701ecb3d1d6d3..e84cb639edfea2c42efd563b72a9be0cc5de6523
2026-03-13 14:34:16 +0000 to 2026-03-21 01:27:07 +0000
- Fix symlink_and_directory when running in a long target dir name (rust-lang/cargo#16775)
- cargo clean: Validate that target_dir is not a file (rust-lang/cargo#16765)
- fix: fetching non-standard git refspecs on non-github repos (rust-lang/cargo#16768)
- Update tar to 0.4.45 (rust-lang/cargo#16771)
- chore: Remove edition_lint_opts from Lint (rust-lang/cargo#16762)
- refactor: split out several smaller changes to prepare for async http (rust-lang/cargo#16763)
- fix(compile): Make build.warnings ignore non-local deps (rust-lang/cargo#16760)
- fix: detect circular publish dependency cycle in workspace publish (rust-lang/cargo#16722)
- refactor(shell): Pull out term integration into `anstyle-progress` (rust-lang/cargo#16757)
- test: reproduce rustfix panic on overlapping suggestions (rust-lang/cargo#16705)
- fix: Avoid panic for package specs with an empty fragment (rust-lang/cargo#16754)
- refactor(registry): avoid dynamic dispatch for Registry trait (rust-lang/cargo#16752)
- refactor(shell): Pull out hyperlink logic into anstyle-hyperlink (rust-lang/cargo#16749)
- refactor(install): Remove dead code (rust-lang/cargo#16718)
Fix typos and markdown errors
This PR fixes some typos and markdown errors I found while writing rust-lang/rust#153697.
I've split it out to reduce the size of that PR.
tests: Activate `must_not_suspend` test for `MutexGuard` dropped before `await`
After bisect it turns out that the test passes in `nightly-2023-09-24` but fails in `nightly-2023-09-23`:
$ rustc +nightly-2023-09-23 --edition 2018 tests/ui/lint/must_not_suspend/mutex-guard-dropped-before-await.rs
error: `MutexGuard` held across a suspend point, but should not be
--> tests/ui/lint/must_not_suspend/mutex-guard-dropped-before-await.rs:13:9
|
13 | let lock = foo.lock().unwrap();
| ^^^^
...
18 | bar().await;
| ----- the value is held across this suspend point
|
That leaves us with
<details>
<summary>git log e4133ba9b1a150..13e6f24b9adda67 --no-merges --oneline </summary>
bffb3467e1 Make test more robust to opts.
44ac8dcc71 Remove GeneratorWitness and rename GeneratorWitnessMIR.
855a75b6d6 Remove useless wrapper.
baa64b0e77 Remove dead error code.
6aa1268900 Bless clippy.
d989e14cf2 Bless mir-opt
211d2ed07b Bless tests.
286502c9ed Enable drop_tracking_mir by default.
a626caaad9 Revert duplication of tests.
ff03204365 Fold lifetimes before substitution.
9450b75986 Do not construct def_path_str for MustNotSuspend.
58ef3a0ec9 diagnostics: simpler 83556 handling by bailing out
79d685325c Check types live across yields in generators too
c21867f9f6 Check that closure's by-value captures are sized
d3dea30cb4 Point at cause of expectation of `break` value when possible
4ed4913e67 Merge `ExternProviders` into the general `Providers` struct
2ba911c832 Have a single struct for queries and hook
9090ed8119 Fix test on targets with crt-static default
5db9a5ee38 Update cargo
9defc971f1 Add tracing instrumentation, just like queries automatically add it
2157f31731 Add a way to decouple the implementation and the declaration of a TyCtxt method.
d5ec9af09d Add test to guard against VecDeque optimization regression
3799af3337 diagnostics: avoid mismatch between variance index and hir generic
34c248d31f compiletest: load supports-xray from target spec
64e27cb4d9 compiletest: load supported sanitizers from target spec
bc7bb3c8e7 compiletest: use builder pattern to construct Config in tests
</details>
of which 286502c9ed (https://github.com/rust-lang/rust/pull/107421) seems most likely. I can't find an existing test except the "inactive" one, so let's simply activate it.
Closesrust-lang/rust#89562 which is where the activated test comes from. The test was originally added in rust-lang/rust#89826.
Tracking issue:
- rust-lang/rust#83310
bootstrap: Optionally print a backtrace if a command fails
I found this quite useful for debugging why a command was failing eagerly (it turns out that `.delay_failure()` is ignored if `fail_fast` is enabled).
Don't emit rustdoc `missing_doc_code_examples` lint on impl items
@lolbinarycat realized in [this comment](https://github.com/rust-lang/rust/pull/153964#discussion_r2953956702) that we weren't testing some cases for the `missing_doc_code_examples` lint. Turns out that it was not handling this case well. =D
So in short: `missing_doc_code_examples` lint should not be emitted on impl items and this PR fixes that.
r? @lolbinarycat
bootstrap: Allow `--bless`ing changes to editor settings files
Previously, on any change you would have to first edit all 4 settings files by hand, then run the tests 4 times in a row to discover what the new hashes are. After this change, you still need to edit the files by hand, but you can now run `x test --bless -- hash` to update the hashes without manually editing them.
ci: add runners for vanilla LLVM 22
Ubuntu 26.04 has `llvm-22` packages that we can test with.
The `Dockerfile` is otherwise the same as the `llvm-21` runners.
Fix bootstrap rust build failure for vxworks
Fixesrust-lang/rust#153332
Starting with VxWorks 25.09, struct stat was updated to use struct timespec instead of time_t for timestamp fields.
The following changes were made in libc in the commit [libc](https://github.com/rust-lang/libc/pull/4781).
As a result, when performing a bootstrap build with VxWorks ≥ 25.09, libc no longer exposes the fields st_mtime, st_atime, and st_ctime, as they are conditionally compiled in src/vxworks/mod.rs here [libc](https://github.com/rust-lang/libc/blob/56caa81b6b433c49c5704bf0400a02d428cfacda/src/vxworks/mod.rs#L229). This causes the build to fail.
For VxWorks versions earlier than 25.09, the build completes successfully without errors.
This PR resolves the issue by detecting the WIND_RELEASE_ID environment variable (which is set in the VxWorks build environment) and conditionally guarding the affected functions in the two additional files where the errors originate.
Do not enable split debuginfo for windows-gnu
Because rustc doesn't handle split debuginfo for these targets, enabling that option causes them to be missing some of the debuginfo.
The test pass in `nightly-2023-09-24` but fail in `nightly-2023-09-23`:
$ rustc +nightly-2023-09-23 --edition 2018 tests/ui/lint/must_not_suspend/mutex-guard-dropped-before-await.rs
error: `MutexGuard` held across a suspend point, but should not be
--> tests/ui/lint/must_not_suspend/mutex-guard-dropped-before-await.rs:13:9
|
13 | let lock = foo.lock().unwrap();
| ^^^^
...
18 | bar().await;
| ----- the value is held across this suspend point
|
Couple of driver interface improvements
* Pass Session to `make_codegen_backend` callback. This simplifies some code in miri.
* Move env/file_depinfo from ParseSess to Session. There is no reason it has to be in ParseSess rather than Session.
* Rename hash_untracked_state to track_state to indicate that it isn't just used for hashing state, but also for adding env vars and files to be tracked through the dep info file.
Flip "region lattice" in RegionKind doc comment
If we assume that references take their region covariantly, and use that to define the subtyping relationship of regions, `'empty` is ⊤ (top) and `'static` is ⊥ (bottom), and that `'a <: 'b` is defined as `'a >= 'b`. However, the RegionKind doc comment's "region lattice" had `'static` at Top. While this is perhaps technically correct (a so-called "region lattice" is not a "type lattice"), it confused me a lot, and took me half an hour to be like "no, ok, I *do* understand things correctly, this region lattice is just flipped from the subtype lattice". Seems better to just have them be the same!
I also took the opportunity to rewrite some parts of the comment with notes that would have helped me when starting out.
Bikesheds welcome (as long as they don't go on forever)!
For context: the comment "`'static` is Top" was [written in 2013](https://github.com/rust-lang/rust/commit/a896440ca1b93cc5dc6edd827ea2ae89602bfa9e#diff-8780054cdf09361c4ac2540c7f544ecfdc52a9e610822aabb8bcd2964affcb1cR430), before there was a [discussion in 2014](https://github.com/rust-lang/rust/issues/15699) that clarified that references take their regions covariantly, and `'a <: 'b` is defined as `'a >= 'b`.
See also Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/RegionKind.20rustc.20doc.20comment
Add the option to run UI tests with the parallel frontend
This PR adds two arguments for tests:
1. `--parallel-frontend-threads`: specify `-Zthread` to compile test case (currently UI tests only)
2. `--iteration-count`: the number of times to run each test
Also, due to the non-deterministic diagnostic orders and cycle errors, this PR adds the directive `//@ ignore-parallel-frontend` to ignore tests with cycle error when the parallel-frontend is enabled (by `--parallel-frontend-threads`) and enables `//@ compare-output-by-lines` by default.
Context: [#t-compiler/parallel-rustc > Add the parallel front-end test suite @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Add.20the.20parallel.20front-end.20test.20suite/near/578781369)
This PR should work with https://github.com/rust-lang/rust/pull/153797 together.
run_make_support: Print the command and output even if it succeeds
Previously, it was quite hard to get access to this output because it was printed to a buffer in memory and then discarded. This output is already hidden behind libtest's output capturing, we don't need to hide it twice.
Previously, it was quite hard to get access to this output because it
was printed to a buffer in memory and then discarded. This output is
already hidden behind libtest's output capturing, we don't need to hide
it twice.
Provide more context on type errors in const context
- On `const` and `static` point at the type (like we do for let bindings)
- On fn calls, point at const parameter in fn definition
- On type, point at const parameter in type definition
- On array type lengths, explain that array length is always `usize`
- On enum variant discriminant, mention `repr`
- On default field value using type parameter, provide more context (Fixrust-lang/rust#147748)
use correct LLVM intrinsic for min/max on floats
The Rust `minnum`/`maxnum` intrinsics are documented to return the other argument when one input is an SNaN. However, the LLVM lowering we currently choose for them does not match those semantics: we lower them to `minnum`/`maxnum`, which (since https://github.com/llvm/llvm-project/pull/172012) is documented to non-deterministically return the other argument or NaN when one input is an SNaN.
LLVM does have an intrinsic with the intended semantics: `minimumnum`/`maximumnum`. Let's use that instead. We can set the `nsz` flag since we treat signed zero ordering as non-deterministic.
Also rename the intrinsics to follow the IEEE 2019 naming, since that is mostly (and in particular, as far as NaN are concerned) now what we do. Also, `minimum_number` and `minimum` are less easy to mix up than `minnum` and `minimum`.
r? @nikic
Cc @tgross35
Fixes https://github.com/rust-lang/rust/issues/149537
Fixes https://github.com/rust-lang/rust/issues/151286
(The issues are only fixed when using the latest supported LLVM, but I don't think we usually track problems specific to people compiling rustc with old versions of LLVM)
These options don't behave reasonably when combined right now, and there
are no tests and no docs for how they should.
For the short term, make this a fatal error. If we decide to assign this
some semantics, then we can do that at any time.
sgasho