Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle autoscoped constructor args with no UUID #11354

Merged
merged 4 commits into from
Oct 18, 2024

Conversation

hubertp
Copy link
Collaborator

@hubertp hubertp commented Oct 17, 2024

Pull Request Description

An application involving >1 autoscoped atom constructor arguments with no ID would lead to a silent type error in GUI. It was silent because once IdMap gets updated, the original type error disappears and users are left with a No_Such_Method on a Panic.

The type error may occur because the compiler was inferring the same UUID for autoscoped constructors. Args with UUID are cached therefore a type confict might occur on the second (or later) argument.

Added a unit test case demonstrating the problem (previously it would fail). The search path is now a bit more careful when inferring UUIDs for arguments.

Closes #11325.

Checklist

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

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    TypeScript,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • Unit tests have been written where possible.
  • If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
    or the Snowflake database integration, a run of the Extra Tests has been scheduled.
    • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

An application involving >1 autoscoped atom constructor arguments
with no ID would lead to a silent type error in GUI. It was silent
because once IdMap gets updated, the original type error disappears and
users are left with a No_Such_Method on a Panic.

The type error may occur because the compiler was inferring the same
UUID for autoscoped constructors. Args with UUID are cached therefore a
type confict might occur on the second (or later) argument.

Added a unit test case demonstrating the problem (previously it would
fail). The search path is now a bit more careful when inferring
arguments.
@hubertp hubertp added the CI: No changelog needed Do not require a changelog entry for this PR. label Oct 17, 2024
@hubertp
Copy link
Collaborator Author

hubertp commented Oct 17, 2024

What probably remains is to make sure that once IdMap arrives, expression updates are being sent. The second half of the unit test demonstrates that this is not necessarily the case.


metadata.assertInCode(idS, code, "Singleton.S 1")
metadata.assertInCode(idX, code, "s.test ..A ..B")
metadata.assertInCode(idRes, code, "x")
Copy link
Member

Choose a reason for hiding this comment

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

+1

@hubertp
Copy link
Collaborator Author

hubertp commented Oct 18, 2024

Re my previous comment regarding lack of expression updates: #11354 (comment)

I imagine the issue is that once UnresolvedConstructor builds the application for autoscoped constructors we are hitting the cached version in https://github.com/enso-org/enso/blob/develop/engine/runtime/src/main/java/org/enso/interpreter/runtime/callable/UnresolvedConstructor.java#L213 and no further construction happens. So I would essentially have to invalidate that when IdMap contains new UUID for the given argument.

GitHub
Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.

@hubertp
Copy link
Collaborator Author

hubertp commented Oct 18, 2024

Re my previous comment regarding lack of expression updates: #11354 (comment)

I was wrong. It's a feature.

@hubertp hubertp merged commit c6ec5c5 into develop Oct 18, 2024
41 checks passed
@hubertp hubertp deleted the wip/hubert/11325-uuids-type-error branch October 18, 2024 18:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

Unexpected Type_Error/Method unknown on project startup
2 participants