-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Open
Labels
A-new-solverBugs from the new solver migration - should be fixed before stable releaseBugs from the new solver migration - should be fixed before stable releaseA-tytype system / type inference / traits / method resolutiontype system / type inference / traits / method resolutionC-bugCategory: bugCategory: bugC-tracking-issueCategory: tracking issueCategory: tracking issue
Description
#20329 opens up great possibilities for the future, but it currently introduces a few regressions in our test suites.
Since the number of regressions is small, and waiting for all of them to be fixed before merging would be inefficient, we’d like to track them here and address them after the PR is merged.
Should fix
-
hir-ty::tests::coercion::coerce_unsize_trait_object_simple
We could learn more from the&S
->&dyn Foo<i8, _>
coercion if we followed the rustc model where unsized is successful if all unsizing trait goals are certain (and non-unsizing goals are delayed).
May not fix / Consider fixing the test case or removing
-
hir-ty::tests::macros::expr_macro_def_expanded_in_various_places
This involves afor
loop desugaring on a type (isize
) that does not implementIterator
. It might not be meaningful to fix this. -
hir-ty::tests::regression::issue_4966
Similar to the above. As the intention of this test is to verify rust-analyzer is not panicking instd::iter::repeat
blows analyzer apart #4966, I think we are okay with this. -
hir-ty::tests::regression::for_loop_block_expr_iterable
Similar to the above. -
hir-ty::tests::simple::regression_19734
As the intention of this test is to verify rust-analyzer is not panicking in Crash when parsing invalid type #19734, I think we are okay with this. -
hir-ty::tests::traits::gats_with_dyn
I think we might remove this as traits with GAT are not dyn-compatible 😆
Not sure. Need some investigation
-
hir-ty::tests::incremental::add_struct_invalidates_trait_solver
-
ide-assists::handlers::generate_from_impl_for_enum::tests::test_generate_from_impl_for_enum_complicated_path
It would be nice to not be required to resolve the path in order to properly generate assists -
ide::goto_implementation::tests::goto_implementation_all_impls
It would be nice to be able to also point to&Foo
ChayimFriedman2 and jackh726
Metadata
Metadata
Assignees
Labels
A-new-solverBugs from the new solver migration - should be fixed before stable releaseBugs from the new solver migration - should be fixed before stable releaseA-tytype system / type inference / traits / method resolutiontype system / type inference / traits / method resolutionC-bugCategory: bugCategory: bugC-tracking-issueCategory: tracking issueCategory: tracking issue