Skip to content

Ucm exits with "No builtin type called: io2.Failure" when calling new IO functions #2027

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

Closed
rlmark opened this issue May 26, 2021 · 2 comments · Fixed by #2033
Closed

Ucm exits with "No builtin type called: io2.Failure" when calling new IO functions #2027

rlmark opened this issue May 26, 2021 · 2 comments · Fixed by #2033
Assignees
Milestone

Comments

@rlmark
Copy link
Contributor

rlmark commented May 26, 2021

When calling some of the new IO functions (I was experimenting with Sockets so the transcript contains that as an example) the following error will surface and the ucm will exit.

No builtin type called: io2.Failure
CallStack (from HasCallStack):
  error, called at src/Unison/Runtime/IOSource.hs:63:16 in unison-parser-typechecker-0.0.0-6U6boimwb8GAC5qrhLfs8h:Unison.Runtime.IOSource

Attached is a transcript which should replicate the issue
fix2027.md

@pchiusano pchiusano added this to the M2 milestone May 26, 2021
@rlmark
Copy link
Contributor Author

rlmark commented May 26, 2021

Also this transcript involves includes pulling all of the base library (🕐 ) but it's actually material for the error to surface.

@pchiusano
Copy link
Member

@dolio I see what's going on - the runtime is referencing IOSource.failureReference (which should have been deleted as it doesn't exist in the Unison source included in IOSource) when it should be referencing Unison.Builtin.Decls.failureRef.

I'm guessing this is only triggered by I/O programs that actually throw errors (and maybe you even have to inspect the type of the error in a certain way to trigger it). I'd delete IOSource.failureReference and add a regression test to io.md transcript that doesn't require pulling all of base.

I'd also audit all the imports of stuff from IOSource in the runtime - most of those should be pointing to things in Unison.Builtin.Decls.

~/unison [trunk●] » rg failureReference 

parser-typechecker/src/Unison/Runtime/Builtin.hs
35:import Unison.Runtime.IOSource (ioFailureReference, tlsFailureReference, eitherReference, failureReference)
907:        . TLetD fail BX (TCon failureReference 0 [stack1, stack2])
917:        . TLetD fail BX (TCon failureReference 0 [stack1, stack2])
930:        . TLetD fail BX (TCon failureReference 0 [stack1, stack2])
943:        . TLetD fail BX (TCon failureReference 0 [stack1, stack2])
957:        . TLetD fail BX (TCon failureReference 0 [stack1, stack2])

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants