fix: unify macro call type with actual type in comptime blocks #11411
+75
−32
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.
| Benchmark suite | Current: 630f649 | Previous: fa8934d | Ratio |
|---|---|---|---|
test_report_zkpassport_noir-ecdsa_ |
3 s |
1 s |
3 |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @TomAFrench
jfecher
reviewed
Jan 30, 2026
Comment on lines
+103
to
108
| if self.in_comptime_context() { | ||
| return; | ||
| } | ||
|
|
||
| let var = RequiredTypeVariable { type_variable_id, typ, kind, location }; | ||
| self.get_function_context_mut().required_type_variables.push(var); |
Contributor
There was a problem hiding this comment.
Suggested change
| if self.in_comptime_context() { | |
| return; | |
| } | |
| let var = RequiredTypeVariable { type_variable_id, typ, kind, location }; | |
| self.get_function_context_mut().required_type_variables.push(var); | |
| if !self.in_comptime_context() { | |
| let var = RequiredTypeVariable { type_variable_id, typ, kind, location }; | |
| self.get_function_context_mut().required_type_variables.push(var); | |
| } |
| /// The reason is that in a comptime context the type of a variable might change | ||
| /// across a loop's iterations, so a type can temporarily remain as `Type<_>` where | ||
| /// `_` is bound by the interpreter evaluating an expression's type being unified with | ||
| /// that type. |
Contributor
There was a problem hiding this comment.
Does this open us up to regular unbound type variables though? E.g. the case this was meant to originally catch may no longer be caught in comptime code?
Comment on lines
+1167
to
+1192
| // Undo any bindings (if any) from the last time we unified this expression's | ||
| // type against the actual type | ||
| if let Some(bindings) = | ||
| self.elaborator.interner.macro_call_expression_bindings.remove(&id) | ||
| { | ||
| for (var, kind, _typ) in bindings.values() { | ||
| var.unbind(var.id(), kind.clone()); | ||
| } | ||
| } | ||
|
|
||
| let mut bindings = TypeBindings::default(); | ||
| match actual_type.try_unify(&expected_type, &mut bindings) { | ||
| Ok(()) => { | ||
| // Store the bindings so we can undo them next time | ||
| self.elaborator | ||
| .interner | ||
| .macro_call_expression_bindings | ||
| .insert(id, bindings.clone()); | ||
| Type::apply_type_bindings(bindings); | ||
| } | ||
| Err(UnificationError) => { | ||
| let error = TypeCheckError::TypeMismatch { | ||
| expected_typ: expected_type.to_string(), | ||
| expr_typ: actual_type.to_string(), | ||
| expr_location: location, | ||
| }; |
Contributor
There was a problem hiding this comment.
Can you factor out all or some of this code? It makes elaborate_call longer and more difficult to understand by getting very involved in a corner case.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Problem
Resolves #11409
Summary
This is a follow-up to #6105
#6105 is good but because we don't unify types, some type variables end up unbound. That's why #11409 was failing.
The solution here is:
This allows a variable to change types across macro loop iterations.
For this I also had to relax the checking of unbound generics when a function context is popped, only in comptime code. The reason is that in the new test here, in
foo.len()we end up withfoowithout a knownN, but it's fine because it's thatNthat we want to infer later on. In this case, ifNends up being used when interpreting the block and it's not bound, we'll get an error anyway.Additional Context
User Documentation
Check one:
PR Checklist
cargo fmton default settings.