Implement Block Label. by Islam-Imad · Pull Request #4535 · Rust-GCC/gccrs

Islam-Imad · 2026-04-21T13:23:00Z

implement block label.

add a label after the end of the block.
when we hit a break with a block label we assign a value to block temp var and goto the end of the block.

dkm · 2026-04-21T13:41:00Z

Hello!

Thanks for this new contribution :)
We're going to try and have more descriptive commit log from now on, when that makes sense. It would be nice in this case to add extra text in the commit log so that readers can have a better idea of the problem you're handling, how you do that, optional issue reference, etc.

Thanks again!

Islam-Imad · 2026-04-21T20:12:18Z

Hello!

Thanks for this new contribution :) We're going to try and have more descriptive commit log from now on, when that makes sense. It would be nice in this case to add extra text in the commit log so that readers can have a better idea of the problem you're handling, how you do that, optional issue reference, etc.

Thanks again!

I have update the commit message and cleanup the remaining stuff :)

thanks Marc

Islam-Imad · 2026-04-28T11:51:53Z

ping ?

CohenArthur

thanks for the work @Islam-Imad :) a couple comments but it looks good to me. I'll leave @philberty to review it as this touches the backend

CohenArthur · 2026-04-28T12:12:20Z

+    // ISSUE HERE :)
+    // let c = 'block_c: {
+    //     break 'block_c 555;
+    // };
+    // dump_number(c);


what is the issue here?

@Islam-Imad It would be worth mentioning it within the code. Please uses Rust-GCC/gccrs#4538

P-E-P

This looks quite good given the amount of changes and their nature. I've put a few comments here and there but this is a great start!

P-E-P · 2026-05-06T11:47:02Z

  std::map<HirId, tree> compiled_fn_map;
  std::map<HirId, tree> compiled_consts;
  std::map<HirId, tree> compiled_labels;
+  std::map<HirId, Bvariable *> compiled_temp_vars;


It just occurred to me that we're using map here but we should probably use unordered_map instead. I don't think we care about the HirdId order. It does not need to be fixed within that PR. We should probably open an issue instead.

yes i agree with you.
The access time will be O(1) instead of O(logn) which is away more faster.
i will open an issue for it and i think it should be good first.

P-E-P · 2026-05-06T12:52:40Z

 {
+  if (expr.has_break_expr () && expr.has_label ())
+    {
+      HIR::Lifetime label = expr.get_label ();


Suggested change

HIR::Lifetime label = expr.get_label ();

HIR::Lifetime& label = expr.get_label ();

P-E-P · 2026-05-06T12:55:09Z

+  if (expr.has_label ())
+    {
+      fncontext fnctx = ctx->peek_fn ();
+      HIR::LoopLabel label = expr.get_label ();


P-E-P · 2026-05-06T13:43:05Z

+  Bvariable *ltemp = nullptr;
+  if (!ctx->lookup_temp_var (ref, &ltemp))
+    {
+      assert (false && "hey we failed to lookup temp var here bro");


Even if those messages are targeted at the developer I'd prefer if we kept things tidy and clean.

Suggested change

assert (false && "hey we failed to lookup temp var here bro");

assert (false && "failed to lookup temp var");

P-E-P · 2026-05-06T13:45:09Z

  std::map<HirId, tree> compiled_fn_map;
  std::map<HirId, tree> compiled_consts;
  std::map<HirId, tree> compiled_labels;
+  std::map<HirId, Bvariable *> compiled_temp_vars;


Couldn't we use compiled_var_decls ? Or do you want to explicitly keep those labels in a separate container ? We need to either rename this or merge both maps.

i didn't notice compiled_var_decls :)
the simple solution is to use it again instead of creating another map.

P-E-P · 2026-05-06T13:51:12Z

+{
+  HirId ref = resolve_NodeId (to_be_resolved);
+  tree label = NULL_TREE;
+  assert (ctx->lookup_label_decl (ref, &label) && "failed to lookup a label");


Please use rust_assert instead, this will insert the file location and help debugging.

Suggested change

assert (ctx->lookup_label_decl (ref, &label) && "failed to lookup a label");

rust_assert (ctx->lookup_label_decl (ref, &label) && "failed to lookup a label");

This change implements backend lowering support for Rust labeled blocks. Previously, labeled blocks were rejected in "CompileExpr::visit(BlockExpr)" as unsupported. With this patch, labeled blocks are lowered by introducing the following :- 1. A backend "LABEL_DECL" used as the jump target for "break 'label". 2. A temporary "Bvariable" used to hold the block’s resulting value. gcc/rust/ChangeLog: * backend/rust-compile-expr.cc (CompileExpr::visit): Lower labeled block. (CompileExpr::construct_block_label): Utility function to construct block label. (CompileExpr::lookup_label): Utility function to lookup label. (CompileExpr::lookup_temp_var): Utility function to lookup block temp variables. (CompileExpr::resolve_util): Utility to resolve NodeId to HirId. * backend/rust-compile-expr.h: Header functions. * resolve/rust-late-name-resolver-2.0.cc (Late::visit): Fix label resolution. gcc/testsuite/ChangeLog: * rust/execute/cf-labeled-block.rs: New test. Signed-off-by: Islam-Imad <islamimad404@gmail.com>

Islam-Imad marked this pull request as draft April 21, 2026 13:23

Islam-Imad force-pushed the implement/block-label branch 3 times, most recently from f5a2a7f to f379578 Compare April 21, 2026 20:02

Islam-Imad marked this pull request as ready for review April 21, 2026 20:12

CohenArthur reviewed Apr 28, 2026

View reviewed changes

CohenArthur requested review from P-E-P, philberty and powerboat9 April 28, 2026 12:13

Islam-Imad force-pushed the implement/block-label branch 2 times, most recently from 2db5b18 to 5982607 Compare April 28, 2026 12:43

P-E-P requested changes May 6, 2026

View reviewed changes

Islam-Imad force-pushed the implement/block-label branch from 5982607 to 50a94d3 Compare May 6, 2026 17:39

	HIR::Lifetime label = expr.get_label ();
	HIR::Lifetime& label = expr.get_label ();

	assert (false && "hey we failed to lookup temp var here bro");
	assert (false && "failed to lookup temp var");

	assert (ctx->lookup_label_decl (ref, &label) && "failed to lookup a label");
	rust_assert (ctx->lookup_label_decl (ref, &label) && "failed to lookup a label");

Conversation

Islam-Imad commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dkm commented Apr 21, 2026

Uh oh!

Islam-Imad commented Apr 21, 2026

Uh oh!

Islam-Imad commented Apr 28, 2026

Uh oh!

CohenArthur left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

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!

P-E-P 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Islam-Imad commented Apr 21, 2026 •

edited

Loading