gccrs: fix(type-check): Resolve 'exceptional' error_mark in visit pattern compilation

[Harishankar14]

This patch fixes two Internal Compiler Errors (ICEs) encountered during compilation.

First, it resolves a crash in CompilePatternLet::visit where the backend panicked upon encountering an error_mark node within a tuple pattern. A check was added to handle erroneous types gracefully.

Second, it fixes a crash in the MarkLive lint pass. Previously, visiting a TypeAlias could trigger rust_unreachable() if the AST-to-HIR mapping lookup failed. This assertion has been removed to allow the compiler to continue execution when the mapping is missing.

Fixes #4161

gcc/rust/ChangeLog:

* backend/rust-compile-pattern.cc (CompilePatternLet::visit): Check for error_mark_node before processing tuple patterns.
* checks/lints/rust-lint-marklive.cc (MarkLive::visit): Remove rust_unreachable() assertion to prevent ICE on missing mappings.

gcc/testsuite/ChangeLog:

* rust/compile/issue-4161.rs: New test.

Thank you for making Rust GCC better!

If your PR fixes an issue, you can add "Fixes #issue_number" into this
PR description and the git commit message. This way the issue will be
automatically closed when your PR is merged. If your change addresses
an issue but does not fully fix it please mark it as "Addresses #issue_number"
in the git commit message.

Here is a checklist to help you with your PR.

• GCC development requires copyright assignment or the Developer's Certificate of Origin sign-off, see https://gcc.gnu.org/contribute.html or https://gcc.gnu.org/dco.html
• Read contributing guidlines
• make check-rust passes locally
• Run clang-format
• Added any relevant test cases to gcc/testsuite/rust/

Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.

*Please write a comment explaining your change. This is the message
that will be part of the merge commit.

[P-E-P]

I'm not 100% confident because I'm not too familiar with that part of the codebase but it feels like you're trying here to fix the symptoms rather than the source of the problem.

[philberty]

This is not the right place to check for this case, it should be in the PathInExpression piece it hits the code there for a more general case i think to start off to investigate there

[philberty]

this isnt the right place to check for this i've loioked into this before there is a more general case we should be trying to catch this its during path code gen not stmt.

Also in your git commit subject you mention type-check.. this is not the type check pass.

[Harishankar14]

@philberty Interesting !! Thanks for the pointer on the previous iteration! I’ve reverted the changes in rust-compile-stmt.cc and moved the logic to the PathInExpression handling as you suggested, the flow was bit confusing to understand.

It turned into a bit of a chain reaction to get this fully stable, but here is what I ended up doing:

1. The Core Fix: I modified ResolvePathRef::resolve_with_node_id (in rust-compile-resolve-path.cc) to handle cases where the type lookup fails (returning false). Instead of asserting/crashing there, I added a check to print a backend error and return error_mark_node so the compiler can recover.

2. Fixing Downstream ICEs: Once I let the error propagate, it triggered crashes further down the pipeline that I also had to patch:

• Pattern Compilation: rust-compile-pattern.cc was crashing because TYPE_MAIN_VARIANT tried to access the error_mark_node. I added a guard clause in CompilePatternLet::visit to return early if the init expression is invalid.
• Linter/Dead Code: The MarkLive pass was asserting when it couldn't look up the HIR ID for the broken Type Alias. I updated rust-lint-marklive.cc to simply skip marking the item as live if the lookup fails, rather than hitting rust_unreachable().

3.Now the issue, which am facing is that it doesn't really throw up an error tbh, it let's it reside silently, which is indeed a huge issue.

I will mark this as draft for now, and will let you know.