feat(hir-ty): add method references_only_ty_error to detect type errors#21497

ileixe · 2026-01-20T07:21:21Z

Add a new method references_only_ty_error to the Ty implementation to determine if a type contains only type errors, ignoring const and lifetime errors. Enhance test suite for const generic method resolution.

Fixes: #21315

Before

(base) ➜  rust-analyzer git:(master) ✗ cargo test -r -p hir-ty -- regression_21315
   Compiling hir-ty v0.0.0 (/root/ys/rust-analyzer/crates/hir-ty)
    Finished `release` profile [optimized] target(s) in 52.49s
     Running unittests src/lib.rs (target/release/deps/hir_ty-7b27e9f23d18774a)

running 1 test
test tests::regression::new_solver::regression_21315_const_generic_method_resolution ... FAILED

failures:

---- tests::regression::new_solver::regression_21315_const_generic_method_resolution stdout ----


error: expect test failed
   --> crates/hir-ty/src/tests/regression/new_solver.rs:515:9

You can update all `expect!` tests by running:

    env UPDATE_EXPECT=1 cargo test

To update a single test, place the cursor on `expect` token and use `run` feature of rust-analyzer.

Expect:
----
127..131 'self': Between<M, _, T>
133..137 '_sep': &'? str
145..151 '_other': Between<M, _, T>
167..187 '{     ...     }': Between<M, _, T>
177..181 'self': Between<M, _, T>
245..249 'self': Self
287..316 '{     ...     }': Between<M, _, Self>
297..304 'Between': fn Between<M, _, Self>(Self) -> Between<M, _, Self>
297..310 'Between(self)': Between<M, _, Self>
305..309 'self': Self
348..352 'self': Self
377..406 '{     ...     }': Between<0, N, Self>
387..394 'Between': fn Between<0, N, Self>(Self) -> Between<0, N, Self>
387..400 'Between(self)': Between<0, N, Self>
395..399 'self': Self
454..531 '{     ...um); }': ()
464..467 'num': Between<1, _, char>
470..473 ''9'': char
470..489 ''9'.at...:<1>()': Between<1, _, char>
499..503 '_ver': Between<1, _, char>
506..509 'num': Between<1, _, char>
506..528 'num.se..., num)': Between<1, _, char>
519..522 '"."': &'static str
524..527 'num': Between<1, _, char>
551..588 '{     ...>(); }': ()
561..564 'num': Between<0, 1, char>
567..570 ''9'': char
567..585 ''9'.at...:<1>()': Between<0, 1, char>

----

Actual:
----
127..131 'self': Between<M, _, T>
133..137 '_sep': &'? str
145..151 '_other': Between<M, _, T>
167..187 '{     ...     }': Between<M, _, T>
177..181 'self': Between<M, _, T>
245..249 'self': Self
287..316 '{     ...     }': Between<M, _, Self>
297..304 'Between': fn Between<M, _, Self>(Self) -> Between<M, _, Self>
297..310 'Between(self)': Between<M, _, Self>
305..309 'self': Self
348..352 'self': Self
377..406 '{     ...     }': Between<0, N, Self>
387..394 'Between': fn Between<0, N, Self>(Self) -> Between<0, N, Self>
387..400 'Between(self)': Between<0, N, Self>
395..399 'self': Self
454..531 '{     ...um); }': ()
464..467 'num': Between<1, _, char>
470..473 ''9'': char
470..489 ''9'.at...:<1>()': Between<1, _, char>
499..503 '_ver': {unknown}
506..509 'num': Between<1, _, char>
506..528 'num.se..., num)': {unknown}
519..522 '"."': &'static str
524..527 'num': Between<1, _, char>
551..588 '{     ...>(); }': ()
561..564 'num': Between<0, 1, char>
567..570 ''9'': char
567..585 ''9'.at...:<1>()': Between<0, 1, char>

----

Diff:
----
127..131 'self': Between<M, _, T>
133..137 '_sep': &'? str
145..151 '_other': Between<M, _, T>
167..187 '{     ...     }': Between<M, _, T>
177..181 'self': Between<M, _, T>
245..249 'self': Self
287..316 '{     ...     }': Between<M, _, Self>
297..304 'Between': fn Between<M, _, Self>(Self) -> Between<M, _, Self>
297..310 'Between(self)': Between<M, _, Self>
305..309 'self': Self
348..352 'self': Self
377..406 '{     ...     }': Between<0, N, Self>
387..394 'Between': fn Between<0, N, Self>(Self) -> Between<0, N, Self>
387..400 'Between(self)': Between<0, N, Self>
395..399 'self': Self
454..531 '{     ...um); }': ()
464..467 'num': Between<1, _, char>
470..473 ''9'': char
470..489 ''9'.at...:<1>()': Between<1, _, char>
499..503 '_ver': Between<1, _, char>{unknown}
506..509 'num': Between<1, _, char>
506..528 'num.se..., num)': Between<1, _, char>{unknown}
519..522 '"."': &'static str
524..527 'num': Between<1, _, char>
551..588 '{     ...>(); }': ()
561..564 'num': Between<0, 1, char>
567..570 ''9'': char
567..585 ''9'.at...:<1>()': Between<0, 1, char>

----



failures:
    tests::regression::new_solver::regression_21315_const_generic_method_resolution

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 945 filtered out; finished in 0.01s

After

(base) ➜  rust-analyzer git:(master) cargo test -r -p hir-ty -- regression_21315
   Compiling hir-ty v0.0.0 (/root/ys/rust-analyzer/crates/hir-ty)
    Finished `release` profile [optimized] target(s) in 52.65s
     Running unittests src/lib.rs (target/release/deps/hir_ty-7b27e9f23d18774a)

running 1 test
test tests::regression::new_solver::regression_21315_const_generic_method_resolution ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 945 filtered out; finished in 0.01s

```

ileixe · 2026-01-20T07:26:04Z

cc @ShoyuVanilla

ShoyuVanilla

Looks good overall, modulo a few nits:

ShoyuVanilla · 2026-01-20T07:40:13Z

crates/hir-ty/src/next_solver/ty.rs

+    fn visit_const(&mut self, c: Const<'db>) -> Self::Result {
+        if c.is_ct_error() { ControlFlow::Continue(()) } else { c.super_visit_with(self) }
+    }


I guess we don't have to implement this, as the default implementation of TypeVisitor::visit_const returns ControlFlow::Continue(()) for error consts?

I confirmed it's indeed default. Removed.

ShoyuVanilla · 2026-01-20T07:55:49Z

crates/hir-ty/src/tests/regression/new_solver.rs

+    // The fix allows method resolution to proceed when only const errors exist,
+    // since const errors unify with any value in structurally_relate_consts.


This comment would be clearer if it were placed directly on the relevant line in method_resolution/probe.rs.

Also, the statement "since const errors unify with any value in structurally_relate_consts" is not quite correct. structurally_relate_consts returns Ok to avoid emitting redundant type mismatch errors once the typecheck is already tainted by error consts. Allowing method resolution to proceed in the presence of error consts is a workaround for our currently incomplete const evaluation, not a reflection of correct or intended behavior.

Thanks for clarification, that was my premature speculation to make me why it's sound. I moved the comment and make it more concise to capture your wording. (also test is re-named to be consistent)

ShoyuVanilla · 2026-01-20T08:17:29Z

crates/hir-ty/src/tests/regression/new_solver.rs

+        r#"
+struct Between<const M: usize, const N: usize, T>(T);
+
+impl<const M: usize, T> Between<M, { usize::MAX }, T> {


I don’t think usize::MAX is suitable here. It is defined in Rust’s core library and is not available in our test suites. We have minicore.rs for a similar purpose, but it does not define usize::MAX.

If the intention is to create an error const by referring a non-existent associated constant, that approach is quite subtle and would benefit from being replaced with a more self-explanatory name. In any case, I think referring to an existing constant would be preferable, especially since we already having trouble resolving such associated constant inside a block.

I'd recommend defining a new ADT with an associated constant and using it instead of usize in this test.

Added new Constant. I did not aware of such infra, and this had const error with different reason!

Add a new method `references_only_ty_error` to the `Ty` implementation to determine if a type contains only type errors, ignoring const and lifetime errors. Enhance test suite for const generic method resolution.

ShoyuVanilla

Thanks!

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 20, 2026

ShoyuVanilla reviewed Jan 20, 2026

View reviewed changes

feat(hir-ty): add method references_only_ty_error to detect type errors

71d114d

Add a new method `references_only_ty_error` to the `Ty` implementation to determine if a type contains only type errors, ignoring const and lifetime errors. Enhance test suite for const generic method resolution.

ileixe force-pushed the issue-21315 branch from b1def95 to 71d114d Compare January 20, 2026 12:42

ileixe requested a review from ShoyuVanilla January 20, 2026 12:46

ShoyuVanilla approved these changes Jan 20, 2026

View reviewed changes

ShoyuVanilla added this pull request to the merge queue Jan 20, 2026

Merged via the queue into rust-lang:master with commit 74afb04 Jan 20, 2026
15 checks passed

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 20, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(hir-ty): add method references_only_ty_error to detect type errors#21497

feat(hir-ty): add method references_only_ty_error to detect type errors#21497
ShoyuVanilla merged 1 commit intorust-lang:masterfrom
ileixe:issue-21315

ileixe commented Jan 20, 2026

Uh oh!

ileixe commented Jan 20, 2026

Uh oh!

ShoyuVanilla left a comment

Uh oh!

ShoyuVanilla Jan 20, 2026

Uh oh!

ileixe Jan 20, 2026

Uh oh!

ShoyuVanilla Jan 20, 2026

Uh oh!

ileixe Jan 20, 2026 •

edited

Loading

Uh oh!

ShoyuVanilla Jan 20, 2026 •

edited

Loading

Uh oh!

ileixe Jan 20, 2026 •

edited

Loading

Uh oh!

ShoyuVanilla left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		// The fix allows method resolution to proceed when only const errors exist,
		// since const errors unify with any value in structurally_relate_consts.

Conversation

ileixe commented Jan 20, 2026

Uh oh!

ileixe commented Jan 20, 2026

Uh oh!

ShoyuVanilla left a comment

Choose a reason for hiding this comment

Uh oh!

ShoyuVanilla Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

ileixe Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

ShoyuVanilla Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

ileixe Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShoyuVanilla Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ileixe Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShoyuVanilla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ileixe Jan 20, 2026 •

edited

Loading

ShoyuVanilla Jan 20, 2026 •

edited

Loading

ileixe Jan 20, 2026 •

edited

Loading