New trait solver migration issues

[Veykril]

Note

We have paused our stable releases for now, if you wish to test the new trait solver please grab a nightly release, install a nightly toolchain component on rustup from after today or use the pre-release channel on VSCode.

This issue is meant to serve as a general collection of issue reports for now.

• metrics are failing on hyper https://github.com/rust-lang/rust-analyzer/actions/runs/16929420980/job/47971698125

[lcnr]

minimal ICEing hir_ty test:

#[test]
fn leak_auto_traits() {
    check_no_mismatches(
        r#"
//- minicore: send
fn foo() -> impl Sized {}

fn is_send<T: Send>(_: T) {}

fn main() {
    is_send(foo());
}
        "#,
    );
}

[lnicola]

Metrics are still failing on webrender-2022 https://github.com/rust-lang/rust-analyzer/actions/runs/16944118963/job/48021096935.

[RoloEdits]

Unsure if its a regression due to this, but after building 70fcdd5 from source, cargo build --release, rust-analyzer analysis-stats . --run-all-ide-things seems to hang indefinitely on:

target/release/rust-analyzer analysis-stats . --run-all-ide-things
Database loaded:     9.49s, 487minstr, 84kb (metadata 362.22ms, 8393kinstr, 13kb; build 9.02s, 3617kinstr, 0b)
  item trees: 1357
  dependency lines of code: 2_317_270, item trees: 5_221
  dependency item stats: traits: 1_654, impl: 24_744, mods: 5_745, macro calls: 8_725, macro rules: 2_060
Item Tree Collection: 3.69s, 41ginstr, 0b
  Total Statistics:
    crates: 57, mods: 1202, decls: 31305, bodies: 30234, adts: 2203, consts: 1349
  Workspace:
    traits: 114, macro_rules macros: 22, proc_macros: 1
    lines of code: 506_352, item trees: 1_357
    usages: traits: 187, impl: 4_422, mods: 1_206, macro calls: 153, macro rules: 126
  Dependencies:
    lines of code: 2_317_270, item trees: 5_221
    declarations: traits: 1_654, impl: 24_744, mods: 5_745, macro calls: 8_725, macro rules: 2_060
Item Collection:     6.93s, 47ginstr, 0b
6003/30234 19% processing: ide_diagnostics::handlers::replace_filter_map_next_with_find_map::tests::replace_filter_map_next_with_find_map_no_diagnostic_with_intervening_metho9618/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_s9/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_supe10200/30234 33% processing: ide_assists::handlers::convert_nested_function_to_closure::tests::convert_nested_function_to_closure_is_not_suggested_if_function_has_generic_paraBody lowering:       5.03s, 34ginstr, 0b
6003/30234 19% processing: ide_diagnostics::handlers::replace_filter_map_next_with_find_map::tests::replace_filter_map_next_with_find_map_no_diagnostic_with_intervening_metho9618/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_s9/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_supe10200/30234 33% processing: ide_assists::handlers::convert_nested_function_to_closure::tests::convert_nested_function_to_closure_is_not_suggested_if_function_has_generic_para  exprs: 919654, ??ty: 118 (0%), ?ty: 110 (0%), !ty: 8
  pats: 202817, ??ty: 55 (0%), ?ty: 113 (0%), !ty: 0
  panics: 0
Inference:           121.11s, 912ginstr, 0b
MIR lowering:        84.87s, 733ginstr, 0b
Mir failed bodies: 66 (0%)
Data layouts:        78.03ms, 412minstr, 0b
Failed data layouts: 0 (0%)
Const evaluation:    32.58ms, 183minstr, 0b
Failed const evals: 10 (0%)

Given what it seems doing, and getting stuck on, I thought I would post this here and see if anyone else has this issue.

[ChayimFriedman2]

@RoloEdits Are you sure it hangs and not just taking a very long time? IDE things in analysis-stats don't have a progress bar.

[jhgg]

I was looking through old issues that were potentially solved by trait solver - many are, some are not. Would it be good to comment on them to start closing out the ones that were fixed - do we want to add a test to r-a before we do so?

[ChayimFriedman2]

@jhgg I think we will want tests.

[RoloEdits]

@ChayimFriedman2

To explain further:

As I want RA to be as fast as possible, I build locally to get a pgo build + native cpu, as well as use mimalloc as an allocator and use linker-plugin-lto so that I can get cross language optimizations at link time. In the step with running with the instrumented binary, it went on for almost a full hour, and still hadn't completed. I then checked that its not some kind of other issue by just using a normal --release build. With that, I ran what you see above for about 20 min and it made no progress beyond that part.

The branch for this is here: https://github.com/RoloEdits/rust-analyzer/tree/build

I tried the same commands with my current RA and reached completion in 4min.

rust-analyzer analysis-stats . --run-all-ide-things
Database loaded:     495.36ms, 449minstr, 84kb (metadata 254.22ms, 7952kinstr, 13kb; build 132.93ms, 4142kinstr, 0b)
  item trees: 1357
  dependency lines of code: 2_317_270, item trees: 5_221
  dependency item stats: traits: 1_653, impl: 24_744, mods: 5_745, macro calls: 8_725, macro rules: 2_060
Item Tree Collection: 2.89s, 32ginstr, 0b
  Total Statistics:
    crates: 57, mods: 1202, decls: 31305, bodies: 30234, adts: 2203, consts: 1349
  Workspace:
    traits: 114, macro_rules macros: 22, proc_macros: 1
    lines of code: 506_352, item trees: 1_357
    usages: traits: 184, impl: 4_422, mods: 1_206, macro calls: 153, macro rules: 126
  Dependencies:
    lines of code: 2_317_270, item trees: 5_221
    declarations: traits: 1_653, impl: 24_744, mods: 5_745, macro calls: 8_725, macro rules: 2_060
Item Collection:     6.15s, 38ginstr, 0b
6003/30234 19% processing: ide_diagnostics::handlers::replace_filter_map_next_with_find_map::tests::replace_filter_map_next_with_find_map_no_diagnostic_with_intervening_metho9618/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_s9/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_supe10200/30234 33% processing: ide_assists::handlers::convert_nested_function_to_closure::tests::convert_nested_function_to_closure_is_not_suggested_if_function_has_generic_paraBody lowering:       4.36s, 29ginstr, 0b
6003/30234 19% processing: ide_diagnostics::handlers::replace_filter_map_next_with_find_map::tests::replace_filter_map_next_with_find_map_no_diagnostic_with_intervening_metho9618/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_s9/30234 31% processing: ide_assists::handlers::extract_module::tests::test_extract_module_for_impl_not_having_corresponding_adt_in_selection_and_not_in_same_mod_but_with_supe10200/30234 33% processing: ide_assists::handlers::convert_nested_function_to_closure::tests::convert_nested_function_to_closure_is_not_suggested_if_function_has_generic_para  exprs: 919654, ??ty: 288 (0%), ?ty: 535 (0%), !ty: 11
  pats: 202817, ??ty: 70 (0%), ?ty: 133 (0%), !ty: 0
  panics: 0
Inference:           144.07s, 973ginstr, 0b
MIR lowering:        38.98s, 286ginstr, 0b
Mir failed bodies: 110 (0%)
Data layouts:        48.65ms, 257minstr, 0b
Failed data layouts: 0 (0%)
Const evaluation:    26.25ms, 147minstr, 0b
Failed const evals: 10 (0%)
2025-08-14T16:34:52.961953844-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964076655-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964096575-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964102055-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964809449-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964816809-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964823789-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964839089-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964850839-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964855619-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.964866319-07:00 ERROR Overloaded deref on type str is not a projection
2025-08-14T16:34:52.965388822-07:00 ERROR Overloaded deref on type str is not a projection
IDE:                 47.71s, 351ginstr, 96b (846 files)
Total:               244.71s, 1713ginstr, 96b

[jhgg]

@jhgg I think we will want tests.

I could see that - but they also might re-test cases that are already covered by tests in rustc/the trait solver itself. What are your thoughts in that regard?

[ShoyuVanilla]

@jhgg I think we will want tests.

I could see that - but they also might re-test cases that are already covered by tests in rustc/the trait solver itself. What are your thoughts in that regard?

Type inferences or trait solvings are not that trivial like "we are using the very same trait solver with rustc so we should get the same results".

There are many things done outside the trait solver, like type coercions or normalizations. At least, assembling goals and feeding it to trait solver is done in our codebase and that's why next-gen solver migration is a great deal of work.

So, I think adding test cases for those issues would not be unnecessary overlapping with rustc.

[ShoyuVanilla]

https://github.com/rust-lang/rust-analyzer/actions/runs/16979863073/job/48137400270

analysis-stats on rust std is panicking

[ChayimFriedman2]

@RoloEdits I investigated this. It because we resolve all assists, and that causes us to appear hang because we're trying to rename the 500 symbols in symbols.rs that have "incorrect case" diagnostic and are used throughout r-a, with a lot of references, including very common words. That's a lot of work, so it appears hang. It now takes a lot longer because trait solving isn't cached.

Which is to say... @rust-lang/rust-analyzer maybe we should bring back caching for trait_solve()? The situation here is extremely unlikely (although I think we train our PGO with --run-all-ide-things, so probably need to change that), but I do fear someone will hit a bad case and their CPU will overheat.