gccrs:fix ICE with continue/break/return in while condition #4270

Harishankar14 · 2025-11-06T20:23:20Z

Fixes ICE when continue/break/return/loop are used as while conditions. The compiler now emits a proper error message instead of crashing.

Fixes #3977

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.

…3977

powerboat9 · 2025-11-08T03:41:25Z

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f4db2628116a78ca94e09a3cf1bcfb21

Having a predicate of type ! should work -- it gets coerced into a boolean. See https://doc.rust-lang.org/reference/types/never.html, though don't get confused by the last paragraph

Harishankar14 · 2025-11-09T10:08:48Z

@powerboat9 Thanks for the feedback! I dont really know how did i miss this.. I've updated the fix to properly handle never-type coercion. Instead of rejecting continue as a value, the compiler now:

Detects when the while predicate has type ! (never)
Coerces it to bool by treating it as true (infinite loop)
Issues a warning about unreachable code

Harishankar14 · 2025-11-09T21:27:51Z

@powerboat9, @philberty

philberty

i think this can be simplified a fair bit but good job.

philberty · 2025-11-10T00:59:45Z

gcc/rust/backend/rust-compile-expr.cc

+  tree condition;
+  if (is_diverging){
+    condition = boolean_true_node;
+  }else{


the code formatting looks wrong you need to use clang format

philberty · 2025-11-10T01:00:29Z

gcc/rust/backend/rust-compile-expr.cc

+  TyTy::BaseType *predicate_type = nullptr;
+  bool ok = ctx->get_tyctx()->lookup_type(predicate.get_mappings().get_hirid(), &predicate_type);
+  bool is_diverging = false;
+  if (ok && predicate_type !=nullptr){


i would do rust_assert (ok and != nullptr) this would be an ICE if it happened

philberty · 2025-11-10T01:01:15Z

gcc/rust/backend/rust-compile-expr.cc

+  bool ok = ctx->get_tyctx()->lookup_type(predicate.get_mappings().get_hirid(), &predicate_type);
+  bool is_diverging = false;
+  if (ok && predicate_type !=nullptr){
+    is_diverging = (predicate_type->get_kind() == TyTy::TypeKind::NEVER 


not sure why your checking for error surely we just use error_mark_node if that happens?

philberty · 2025-11-10T01:01:54Z

gcc/rust/backend/rust-compile-expr.cc

+                    || predicate_type->get_kind() == TyTy::TypeKind::ERROR);
+  }
+  tree condition;
+  if (is_diverging){


i think this becomes:

if (predicate_type->isTyTy::NeverType ())

I think reads better

philberty · 2025-11-10T01:02:45Z

gcc/rust/backend/rust-compile-expr.cc

+    condition = boolean_true_node;
+  }else{
+    condition = CompileExpr::Compile(predicate,ctx);
+    if(condition == error_mark_node || TREE_TYPE(condition) == NULL_TREE){


hmm checking for TREE_TYPE null seems odd.. surely its just if error_mark_node? if not you should add a comment

I was overcautious.. i guess.But i agree, with you. It was unwanted.
Fixed it.

philberty · 2025-11-10T01:04:38Z

gcc/rust/typecheck/rust-hir-type-check-expr.cc

-		     block_expr->as_string ().c_str ());
+         "expected %<()%> got %s",
+         block_expr->as_string ().c_str ());
+      infered = new TyTy::ErrorType (expr.get_mappings ().get_hirid ());


i think the type check expression defaults infered to be an error type anyways I don't think you need this

philberty · 2025-11-10T01:05:10Z

gcc/rust/typecheck/rust-hir-type-check-expr.cc

+  if (block_expr->get_kind () == TyTy::TypeKind::ERROR)
+    {
+      infered = new TyTy::ErrorType (expr.get_mappings ().get_hirid ());
+      context->pop_loop_context ();


same here the Resolve call checks for nullptr and makes an error type if you read the top of this file

philberty · 2025-11-10T01:05:55Z

gcc/rust/typecheck/rust-hir-type-check-expr.cc

+    = TypeCheckExpr::Resolve (expr.get_predicate_expr ());
+  if (predicate_type->get_kind () == TyTy::TypeKind::ERROR)
+    {
+      infered = new TyTy::ErrorType (expr.get_mappings ().get_hirid ());


yeah just pop and return dont need to explicitly set error type here

Harishankar14 · 2025-11-11T13:40:45Z

@philberty LMK, if any changes required. Applied all the ones which you pointed out. :)

Harishankar14 · 2025-11-13T09:56:02Z

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f4db2628116a78ca94e09a3cf1bcfb21

Having a predicate of type ! should work -- it gets coerced into a boolean. See https://doc.rust-lang.org/reference/types/never.html, though don't get confused by the last paragraph

@powerboat9 This should do, lmk your thoughts.

powerboat9 · 2025-11-14T22:12:13Z

gcc/rust/backend/rust-compile-expr.cc

+  tree condition;
+  if (predicate_type->get_kind () == TyTy::TypeKind::NEVER)
+    {
+      condition = boolean_true_node;


The predicate expression should still be evaluated, as otherwise code that executes but never returns is skipped and continued past.

Hmm, interesting, i guess even though it returns nothing, might have side effects (like function calls) that should still execute, even though it never returns.I guess that is what you meant right @powerboat9

Yep. For example,

fn foo() { while panic!("stop immediately") { break } never_ever_call_this (); }

@powerboat9 understood, will fix it and let you know !!

@powerboat9 I have done the changes, tested it out with few testcases and examples, works !! Sorry for the multiple request notif..Some bug within my side from github

It's alright. It looks like the code is still broken though -- if the condition doesn't actually make it into the final tree output, it won't make it into the final compiled program.

@powerboat9 Ah !! Sorry i pushed the wrong code.
#4270 (comment)
My solution was l

if (condition == error_mark_node) { condition = boolean_true_node; } else if (predicate_type->get_kind() == TyTy::TypeKind::NEVER) { // The predicate was compiled and added to the tree. // For NEVER type, we need to ensure it's in the output, so explicitly add it ctx->add_statement(condition); condition = boolean_true_node; }

Haven't committed or updated yet.. But yeah go through this and lmk !!

fn side_effect() ->i32{ 42 }

fn never_returns(_x: i32) -> ! { loop {} }

fn test_nested() { while never_returns(side_effect()) { break; } // side_effect() must be compiled and evaluated before never_returns() }

fn main() { if false { test_nested(); } }

Test Output.

powerboat9 · 2025-11-16T05:22:35Z

gcc/rust/backend/rust-compile-expr.cc

+  tree condition;
+  if (predicate_type->get_kind () == TyTy::TypeKind::NEVER)
+    {
+      condition = boolean_true_node;


It's alright. It looks like the code is still broken though -- if the condition doesn't actually make it into the final tree output, it won't make it into the final compiled program.

gcc/rust/typecheck/rust-hir-type-check-expr.cc

philberty

nearly there

philberty · 2025-11-17T19:33:27Z

gcc/rust/backend/rust-compile-expr.cc

+    = ctx->get_tyctx ()->lookup_type (predicate.get_mappings ().get_hirid (),
+				      &predicate_type);
+  rust_assert (ok && predicate_type != nullptr);
+  tree condition;


you dont need to declare the variable seperate just do tree condition = CompileExpr::Compile (predicate, ctx)

@philberty Haha yeah, that was ugly, fixed.

philberty · 2025-11-17T19:36:32Z

gcc/rust/backend/rust-compile-expr.cc

+  rust_assert (ok && predicate_type != nullptr);
+  tree condition;
+  condition = CompileExpr::Compile (predicate, ctx);
+  if (condition == error_mark_node)


you can just ignore the case of condition == error mark node... because it will show up in -fdump-tree-gimple, not sure how it could error something else should spit out and error message so i would just do:

tree condition = CompileExpr::Compile (predicate, ctx); if (predicate_type->get_kind() == TyTy::TypeKind::NEVER) { // The predicate was compiled and added to the tree. // For NEVER type, we need to ensure it's in the output, so explicitly add it ctx->add_statement(condition); condition = boolean_true_node; }

@philberty Resolved.

Fixes Rust-GCC#3977 The predicate expression must be evaluated before type checking to ensure side effects occur even when the predicate has never type. This prevents skipping function calls, panics, or other side effects in diverging predicates. gcc/rust/ChangeLog: * backend/rust-compile-expr.cc (CompileExpr::visit): Always evaluate predicate expression before checking for never type to preserve side effects in while loop conditions. gcc/testsuite/ChangeLog: * rust/compile/issue-3977.rs: New test. Signed-off-by: Harishankar <harishankarpp7@gmail.com>

Harishankar14 changed the title ~~Fix ICE with continue/break/return in while condition,Fixes #3977~~ gccrs:Fix ICE with continue/break/return in while condition,Fixes #3977 Nov 6, 2025

Harishankar14 force-pushed the fold-convert branch 2 times, most recently from 2f08a77 to 6e26f4c Compare November 7, 2025 06:19

Harishankar14 changed the title ~~gccrs:Fix ICE with continue/break/return in while condition,Fixes #3977~~ gccrs:fix ICE with continue/break/return in while condition,fixes #3977 Nov 7, 2025

Harishankar14 changed the title ~~gccrs:fix ICE with continue/break/return in while condition,fixes #3977~~ gccrs:fix ICE with continue/break/return in while condition Nov 7, 2025

Harishankar14 force-pushed the fold-convert branch 3 times, most recently from ea6ad41 to bd1e92a Compare November 7, 2025 07:20

Harishankar14 marked this pull request as draft November 7, 2025 08:28

Fix ICE with continue/break/return in while condition,Fixes Rust-GCC#…

e90c207

…3977

Harishankar14 force-pushed the fold-convert branch from bd1e92a to e90c207 Compare November 7, 2025 11:33

Harishankar14 force-pushed the fold-convert branch from 188c257 to e1e3018 Compare November 9, 2025 20:43

Harishankar14 marked this pull request as ready for review November 9, 2025 21:26

philberty requested changes Nov 10, 2025

View reviewed changes

Harishankar14 force-pushed the fold-convert branch 2 times, most recently from 58fd25a to 9daabe7 Compare November 10, 2025 08:11

Harishankar14 requested a review from philberty November 10, 2025 08:53

Harishankar14 force-pushed the fold-convert branch from 9daabe7 to 7e79af7 Compare November 11, 2025 06:34

powerboat9 reviewed Nov 14, 2025

View reviewed changes

Harishankar14 force-pushed the fold-convert branch from 7e79af7 to d9c0e76 Compare November 15, 2025 10:58

Harishankar14 marked this pull request as draft November 15, 2025 11:09

Harishankar14 force-pushed the fold-convert branch from d9c0e76 to 8592239 Compare November 15, 2025 11:15

Harishankar14 marked this pull request as ready for review November 15, 2025 12:04

Harishankar14 requested review from powerboat9 November 15, 2025 12:05

Harishankar14 requested a review from powerboat9 November 15, 2025 12:05

powerboat9 requested changes Nov 16, 2025

View reviewed changes

Harishankar14 force-pushed the fold-convert branch from 8592239 to 06051e0 Compare November 17, 2025 17:21

powerboat9 reviewed Nov 17, 2025

View reviewed changes

gcc/rust/typecheck/rust-hir-type-check-expr.cc Outdated Show resolved Hide resolved

Harishankar14 force-pushed the fold-convert branch 2 times, most recently from 0007616 to e14f017 Compare November 17, 2025 19:33

philberty requested changes Nov 17, 2025

View reviewed changes

Harishankar14 force-pushed the fold-convert branch from e14f017 to c2a70d2 Compare November 17, 2025 23:11

Harishankar14 requested a review from philberty November 18, 2025 07:00

gccrs:fix ICE with continue/break/return in while condition #4270

Are you sure you want to change the base?

gccrs:fix ICE with continue/break/return in while condition #4270

Conversation

Harishankar14 commented Nov 6, 2025

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

Uh oh!

powerboat9 commented Nov 8, 2025

Uh oh!

Harishankar14 commented Nov 9, 2025

Uh oh!

Harishankar14 commented Nov 9, 2025

Uh oh!

philberty left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Harishankar14 commented Nov 11, 2025

Uh oh!

Harishankar14 commented Nov 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Harishankar14 Nov 15, 2025 • 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!

Choose a reason for hiding this comment

Uh oh!

Harishankar14 Nov 16, 2025 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

philberty left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Harishankar14 Nov 15, 2025 •

edited

Loading

Harishankar14 Nov 16, 2025 •

edited

Loading