-
Notifications
You must be signed in to change notification settings - Fork 323
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
Conversation
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.
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") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
Re my previous comment regarding lack of expression updates: #11354 (comment) I imagine the issue is that once
|
I was wrong. It's a feature. |
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:
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
or the Snowflake database integration, a run of the Extra Tests has been scheduled.