Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gccrs: Fix bad handling for recursive type query #3250

Merged
merged 1 commit into from
Nov 12, 2024
Merged

Conversation

philberty
Copy link
Member

When resolving a type like this which is generic it causes the argument substitution to go through bounds checking which is expected. But this can call a type bounds probe which again calls a type query which will be on the Impl Type on an impl block which can result in a recursive type query which does eventually get caught and errors correctly. But this then triggers some old error diagnositcs which are not valid error codes but old error messages we used to catch simple errors very early on which do not apply for this senario.

Fixes #2905

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::resolve_impl_block_substitutions): dont check for unconstrained when the self is not resolved
* typecheck/rust-hir-type-check-type.cc (TypeCheckType::resolve_root_path): remove bad debug error diagnostic
* typecheck/rust-tyty-subst.cc: likewise

gcc/testsuite/ChangeLog:

* rust/compile/nr2/exclude: nr2 cant handle this
* rust/compile/issue-2905-1.rs: New test.
* rust/compile/issue-2905-2.rs: New test.

When resolving a type like this which is generic it causes the argument
substitution to go through bounds checking which is expected. But this
can call a type bounds probe which again calls a type query which will be
on the Impl Type on an impl block which can result in a recursive type
query which does eventually get caught and errors correctly. But this then
triggers some old error diagnositcs which are not valid error codes but old
error messages we used to catch simple errors very early on which do not
apply for this senario.

Fixes #2905

gcc/rust/ChangeLog:

	* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::resolve_impl_block_substitutions):
	dont check for unconstrained when the self is not resolved
	* typecheck/rust-hir-type-check-type.cc (TypeCheckType::resolve_root_path):
	remove bad debug error diagnostic
	* typecheck/rust-tyty-subst.cc: likewise

gcc/testsuite/ChangeLog:

	* rust/compile/nr2/exclude: nr2 cant handle this
	* rust/compile/issue-2905-1.rs: New test.
	* rust/compile/issue-2905-2.rs: New test.

Signed-off-by: Philip Herron <[email protected]>
Copy link
Member

@CohenArthur CohenArthur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perfect, thank you!!!

Merged via the queue into master with commit 680ad46 Nov 12, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Weird root segment type resolution issue depending on order of items?
2 participants