Remove the `anon` query modifier
Prior experiments:
- https://github.com/rust-lang/rust/pull/152268
- https://github.com/rust-lang/rust/pull/153996
[Zulip thread: *Removing the `anon` query modifier*](https://rust-lang.zulipchat.com/#narrow/channel/582699-t-compiler.2Fquery-system/topic/Removing.20the.20.60anon.60.20query.20modifier/with/580760962)
---
There are currently three queries that use the `anon` modifier:
- `check_representability`
- `check_representability_adt_ty`
- `erase_and_anonymize_regions_ty`
It seems that none of them are using `anon` in an essential way.
According to comments and tests, the *representability* queries mainly care about not being eligible for forcing (despite having a recoverable key type), so that if a cycle does occur then the entire cycle will be on the query stack. Replacing `anon` with a new `no_force` modifier gives a modest perf improvement.
The `erase_and_anonymize_regions_ty` query appears to be using `anon` to reduce the dep-graph overhead of a query that is expected to not call any other queries (and thus have no dependencies). Replacing `anon` with either `no_hash` or nothing appears to give only a very small perf hit on `cargo` benchmarks, which is justified by the fact that it lets us remove a lot of machinery for anonymous queries.
We still need to retain some of the machinery for anonymous *tasks*, because the non-query task `DepKind::TraitSelect` still uses it.
---
I have some ideas for a follow-up that will reduce dep-graph overhead by replacing *all* zero-dependency nodes with a singleton node, but I want to keep that separate in case it causes unexpected issues and needs to be bisected or reverted.
Make `par_slice` consistent with single-threaded execution
rust-lang/rust#152375 removed this consistency by switching from order preserving join to scope, which does not preserve order as stated in `par_fns` as well. This also makes `par_slice` behavior consistent with `par_fns`.
Example
---
```rust
fn foo() {
let x;
x =$0 n + 100;
}
```
**Before this PR**
Assist not applicable
**After this PR**
```rust
fn foo() {
let x;
x = {
n + 100
};
}
```
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)
According to its comment, this query was only using `anon` to save a little bit
of work for a dep graph node that is expected to have no dependencies.
Benchmarks indicate that the perf loss, if any, is small enough to be justified
by the fact that we can now remove support for `anon` queries.
Adding `no_hash` appears to give marginally better perf results.
These queries appear to have been using `anon` for its side-effect of making
them ineligible for forcing.
According to their comments and also `tests/incremental/issue-61323.rs`, these
queries want to avoid forcing so that if a cycle does occur, the whole cycle
will be on the query stack for the cycle handler to find.
Start migrating `DecorateDiagCompat::Builtin` items to `DecorateDiagCompat::Dynamic`
Part of https://github.com/rust-lang/rust/issues/153099.
End goal being to completely remove the two steps currently required by `DecorateDiagCompat::Builtin` and remove duplicated types.
r? @JonathanBrouwer
don't suggest non-deriveable traits for unions
Fixesrust-lang/rust#137587
Before, the compiler suggested adding `#[derive(Debug)]` (other traits too) for unions,
which is misleading because some traits can't be automatically derived.
Only traits that are still suggested are Copy and Clone.
I noticed the error label changed after removing the suggestion. I hope this isn't a big deal, but let me know if that's an issue.
original example:
```rs
union Union {
member: usize,
}
impl PartialEq<u8> for Union {
fn eq(&self, rhs: &u8) -> bool {
unsafe { self.member == (*rhs).into() }
}
}
fn main() {
assert_eq!(Union { member: 0 }, 0);
}
```
before:
```
error[E0277]: `Union` doesn't implement `Debug`
--> src\main.rs:13:5
|
13 | assert_eq!(Union { member: 0 }, 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Debug` is not implemented for `Union`
|
= note: add `#[derive(Debug)]` to `Union` or manually `impl Debug for Union`
= note: this error originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider annotating `Union` with `#[derive(Debug)]`
|
2 + #[derive(Debug)]
3 | union Union {
|
```
after (the message doesn't suggest adding #[derive(Debug)] to unions)
```
error[E0277]: `Union` doesn't implement `Debug`
--> src\main.rs:13:5
|
13 | assert_eq!(Union { member: 0 }, 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Debug` is not implemented for `Union`
--> src\main.rs:2:1
|
2 | union Union {
| ^^^^^^^^^^^
= note: manually `impl Debug for Union`
```
Allow passing `expr` metavariable as `cfg` predicate
This PR allows expanding `expr` metavariables inside the configuration predicates of `cfg` and `cfg_attr` invocations.
For example, the following code will now compile:
```rust
macro_rules! mac {
($e:expr) => {
#[cfg_attr($e, inline)]
#[cfg($e)]
fn func() {}
#[cfg(not($e))]
fn func() {
panic!()
}
}
}
mac!(any(unix, feature = "foo"));
```
There is currently no `macro_rules` fragment specifier that can represent all valid `cfg` predicates. `meta` comes closest, but excludes `true` and `false`. By fixing that, this change makes it easier to write declarative macros that parse `cfg` or `cfg_attr` invocations, for example https://github.com/rust-lang/rust/pull/146281/.
@rustbot label T-lang needs-fcp A-attributes A-cfg A-macros
tests/ui/async-await/drop-option-future.rs: New regression test
The test began compiling with `nightly-2022-11-25`. I bisected it further, and the commit that made it compile was 9f36f988ad (rust-lang/rust#104321). The test fails to compile with `nightly-2022-11-24`:
$ rustc +nightly-2022-11-24 --edition 2018 tests/ui/async-await/drop-option-future.rs
error[E0597]: `value` does not live long enough
--> tests/ui/async-await/drop-option-future.rs:12:22
|
12 | f = Some(async { value });
| --^^^^^--
| | |
| | borrowed value does not live long enough
| value captured here by generator
13 | core::mem::drop(f);
14 | }
| -
| |
| `value` dropped here while still borrowed
| borrow might be used here, when `f` is dropped and runs the destructor for type `Option<impl Future<Output = i32>>`
The fix 9f36f988ad does not appear to affect or include a regression test for the rust-lang/rust#98077 case, so let's add that test.
Closesrust-lang/rust#98077 since we add the test from that issue.
Emit fewer errors for incorrect rtn and `=` -> `:` typos in bindings
Make all existing `:` -> `=` typo suggestions verbose and tweak the suggested code.
Stash parse errors when pasing rtn that doesn't use `(..)`.
Emit single error on `Foo::bar(qux)` that looks like rtn in incorrect position and suggest `Foo::bar(..)`.
```
error: return type notation not allowed in this position yet
--> $DIR/let-binding-init-expr-as-ty.rs:18:10
|
LL | struct K(S::new(()));
| ^^^^^^^^^^
|
help: furthermore, argument types not allowed with return type notation
|
LL - struct K(S::new(()));
LL + struct K(S::new(..));
|
```
On incorrect rtn in let binding type for an existing inherent associated function, suggest `:` -> `=` to turn the "type" into a call expression. (Fixrust-lang/rust#134087)
```
error: expected type, found associated function call
--> $DIR/let-binding-init-expr-as-ty.rs:29:12
|
LL | let x: S::new(());
| ^^^^^^^^^^
|
help: use `=` if you meant to assign
|
LL - let x: S::new(());
LL + let x = S::new(());
|
```
Jonathan Brouwer