Skip to content

Conversation

@Akirathan
Copy link
Member

@Akirathan Akirathan commented Dec 19, 2025

Fixes #10465

Pull Request Description

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • Revert 81b2c82
  • The documentation has been updated, if necessary.
  • All code follows the
    Scala,
    Java
  • Unit tests have been written where possible.

@Akirathan Akirathan self-assigned this Dec 19, 2025
@Akirathan Akirathan added the CI: No changelog needed Do not require a changelog entry for this PR. label Dec 19, 2025
@Akirathan Akirathan changed the title Add failing case tests Pattern match does not evaluate suspended atom fields Dec 19, 2025
@Akirathan Akirathan added the CI: Clean build required CI runners will be cleaned before and after this PR is built. label Dec 19, 2025
Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Nice
  • If we are green, then let's go!

case v2 of
My_Ref.Eager e -> e
My_Ref.Lazy l ->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I'd be interested in ensuring that My_Ref.Lazy l:Integer case match does work as expected (e.g. it does evaluate the l field)
  • Maybe also that My_Ref.Lazy l:Text fails

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added tests for it in a403dab. Currently, they are failing, because the type assertion forces the field to be evaluated. I will need to implement also lazy type checking for this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I think you can change the tests, to "materialize" the lazy field.
  • we need the real value to perform the type check
  • so "materializing" the field is OK
  • I just wanted to cover that behavior with a test

arr[i] = structsLib.getField(obj, i);
// Wrap suspended fields in functions, so that they are not evaluated
// too eagerly.
if (fields[i].isSuspended() && obj instanceof Atom atom) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • idea: Shouldn't there be structsLib.isSuspended(obj, i)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like a better idea than this hack with instanceof. I will implement this new message.

return Function.fullyApplied(getFieldNode.getCallTarget());
}

private static final class GetSuspendedFieldNode extends RootNode {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • there already is LazyCheckRootNode which is quite similar
  • is some unification possible/desirable?
  • why is this a RootNode and not ClosureEnsoNode?
  • will it be properly represented in stacktraces? LazyCheckRootNode probably isn't...

* @param resolvedCons The actual constructor resolved at runtime.
* @return
*/
private def atomFieldsAsArguments(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be a method in AtomConstructor? Not taking Pattern.Constructor, but for example String[] fieldsAsName argument? It seems to me this is quite constructor specific behavior that'd be better encapsulated in AtomConstructor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CI: Clean build required CI runners will be cleaned before and after this PR is built. CI: No changelog needed Do not require a changelog entry for this PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Pattern matching with _ forces computation of lazy fields too eagerly

3 participants