Fix unbound variable error when matching on const record subjects by IgorCastejon · Pull Request #5302 · gleam-lang/gleam

IgorCastejon · 2026-01-19T20:57:22Z

Closes #5261.

The changes in this PR have been discussed beforehand in an issue
The issue for this PR has been linked
Tests have been added for new behaviour
The changelog has been updated for any user-facing changes

IgorCastejon · 2026-01-19T21:00:48Z

compiler-core/src/type_/pattern.rs

+                    ValueConstructorVariant::ModuleConstant { .. } => {
+                        // If the variable is a constant we shadow it with the refined type.
+                        // We cannot convert it to a local variable as that would cause the
+                        // code generator to look for a runtime variable that doesn't exist.
+                        let mut refined_constant = variable.clone();
+                        refined_constant.type_ = type_;
+                        let _ = self.environment.scope.insert(name, refined_constant);
+                    }


I added this specific block to allow field access of const records (like user.name) to work inside the branch, matching the current behavior for local variables.

However, I noticed that Gleam doesn't do this type refinement for constants globally:
Gleam playground

Since the fix for the runtime crash doesn't strictly require this part (we could just ignore ModuleConstant entirely here), I have two questions:

Should I keep or remove this code?

Should I open a separate issue about global type refinement for constants (or is the current behavior deliberate)?

Yeah I'd open a second separate issue for type refinements of constants and not add any code related to refinement in this PR. Makes it easier to review!

This worked in the JavaScript target, but for the Erlang target it would generate an invalid local variable:
Gleam playground

So removing this code now results in a compiler error that would break existing code. Should I still remove it?

I've created an issue: #5310

Should this be removed now then?

I've talked with @giacomocavalieri and we agreed the code should be kept! Otherwise, removing it will break variant inference for consts, which is currently possible in the JavaScript target.

IgorCastejon · 2026-01-19T21:09:42Z

...shots/gleam_core__javascript__tests__case__local_variable_as_case_subject_shadows_const.snap

+source: compiler-core/src/javascript/tests/case.rs
+expression: "\npub type Wibble {\n  Wibble\n  Wobble(int: Int)\n}\n\nconst wibble = Wibble\n\npub fn main() {\n  echo wibble\n  // This 'wibble' shadows the const\n  let wibble = Wobble(42)\n  case wibble {\n    // This matches the local variable, not the const\n    Wobble(_) -> wibble\n  }\n}\n"
+---
+----- SOURCE CODE
+
+pub type Wibble {
+  Wibble
+  Wobble(int: Int)
+}
+
+const wibble = Wibble
+
+pub fn main() {
+  echo wibble
+  // This 'wibble' shadows the const
+  let wibble = Wobble(42)
+  case wibble {
+    // This matches the local variable, not the const
+    Wobble(_) -> wibble
+  }
+}


Just something of interest I noticed while testing: if a const is defined but unused, it is properly optimized out of the generated JavaScript, but it still seems to have its name reserved in the variable generator.
Gleam playground

...ots/gleam_core__javascript__tests__case__local_variable_record_access_variant_inference.snap

giacomocavalieri · 2026-01-21T13:58:29Z

compiler-core/src/type_/pattern.rs

+                    ValueConstructorVariant::ModuleConstant { .. } => {
+                        // If the variable is a constant we shadow it with the refined type.
+                        // We cannot convert it to a local variable as that would cause the
+                        // code generator to look for a runtime variable that doesn't exist.
+                        let mut refined_constant = variable.clone();
+                        refined_constant.type_ = type_;
+                        let _ = self.environment.scope.insert(name, refined_constant);
+                    }


Yeah I'd open a second separate issue for type refinements of constants and not add any code related to refinement in this PR. Makes it easier to review!

lpil

Thank you!! I've left some questions inline 🙏

lpil · 2026-02-05T15:05:55Z

compiler-core/src/type_/pattern.rs

+                        // code generator to look for a runtime variable that doesn't exist.
+                        let mut refined_constant = variable.clone();
+                        refined_constant.type_ = type_;
+                        let _ = self.environment.scope.insert(name, refined_constant);


Remove the references to refinement types please

lpil · 2026-02-05T15:07:02Z

compiler-core/src/type_/pattern.rs

+                    ValueConstructorVariant::ModuleConstant { .. } => {
+                        // If the variable is a constant we shadow it with the refined type.
+                        // We cannot convert it to a local variable as that would cause the
+                        // code generator to look for a runtime variable that doesn't exist.
+                        let mut refined_constant = variable.clone();
+                        refined_constant.type_ = type_;
+                        let _ = self.environment.scope.insert(name, refined_constant);
+                    }


Should this be removed now then?

...ots/gleam_core__javascript__tests__case__local_variable_record_access_variant_inference.snap

lpil · 2026-02-05T15:11:17Z

...ts/snapshots/gleam_core__javascript__tests__case__const_record_access_variant_inference.snap

+  } else {
+    return wibble.int;
+  }
+}


How come this is generating flow control instead of returning 24 unconditionally like it would with let wibble = Wobble(42)?

Sounds like a separate issue, the code was already generated like this before this PR:
Gleam Playground

…st names

IgorCastejon commented Jan 19, 2026

View reviewed changes

IgorCastejon force-pushed the fix/const-record-as-case-subject-bug branch from 90fd708 to a071320 Compare January 19, 2026 21:54

giacomocavalieri reviewed Jan 21, 2026

View reviewed changes

giacomocavalieri mentioned this pull request Jan 29, 2026

fix(erlang): fix unbound variable error with const records in case #5334

Closed

2 tasks

IgorCastejon force-pushed the fix/const-record-as-case-subject-bug branch from a071320 to f70a809 Compare January 31, 2026 01:29

lpil reviewed Feb 5, 2026

View reviewed changes

lpil marked this pull request as draft February 5, 2026 15:11

IgorCastejon added 3 commits February 21, 2026 12:33

Fix unbound variable error when matching on const record subjects

1cd31e8

Add variant inference test case for const record access and adjust te…

242f99e

…st names

Remove references to "type refinement" in favor of "variant inference"

b4a9b70

IgorCastejon force-pushed the fix/const-record-as-case-subject-bug branch from f70a809 to b4a9b70 Compare February 21, 2026 15:39

Fix new cargo fmt

ea857b9

IgorCastejon marked this pull request as ready for review February 21, 2026 16:04

Uh oh!

Conversation

IgorCastejon commented Jan 19, 2026

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lpil 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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IgorCastejon Feb 21, 2026 • 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

IgorCastejon Feb 21, 2026 •

edited

Loading