Better context info in Type_Error raised from return type checks

[radeusgd]

Pull Request Description

• Followup to Opt-in return type checks #8502 that adds better error messages

Important Notes

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,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[radeusgd]

Example:

from Standard.Base import all

go x -> Integer =
    if x == 0 then 1 else
        if x == 10 then "TXT" else
            @Tail_Call go x-1

main =
    IO.println <| go 4
    IO.println <| go 12

yields:

1
Execution finished with an error: Type error: expected `go` result to be Integer, but got Text.
        at <enso> test.go(test.enso:3-6)
        at <enso> test.main(test.enso:10:5-23)

[radeusgd]

This is a simple approach to ensuring better error messages - when creating the type ascriptions that enforce the type checks, we add a 'comment' to it that will then drive the error message.

I was thinking of implementing a slightly cleaner approach where instead of adding the comment to the IR, we could deduce this in an IR pass from context (detecting the type check at the return of a function), but this seemed like a much simpler solution.

Still I can try to do the 'better' one if we think this is not good.

Alternative solution

I think the toher solution may need then to actually change the overall appproach to type checks - remove the Type.Ascriptions added for return checks, instead adding some return type information to the IR of particular Functions or Methods. Then that type info can be used in a separate ReturnType pass that would generate the ReadArgumentCheckNode with proper comments.

---

I think regardless of this PR, I will try to experiment a bit with the current approach and see if this approach works well with the next steps of most basic type inference/propagation/checking. If I see that actually there the 'Alternative Solution' would be more desirable anyway, that may mean we should take it and scratch this PR - that's why I separated it from the base PR.

[JaroslavTulach]

Computing a "comment" automatically and attaching it to IR is fine. There is #8419 to start an effort of checking what's the fastest thing for runtime-compiler to do.

[JaroslavTulach]

Shouldn't this be expecting 'x' to return Integer, but got Text?

[radeusgd]

Yes I think that form may be more readable, I will update it.

[Akirathan]

This definitely feels like a better error message for an unexpected return type from a method. I have even a better suggestion, I think.

[Akirathan]

What about the following error message:

expected the result of `plusChecked` method to be Integer, but got Text

Isn't that even better?

[radeusgd]

sure it sounds good to me, I will amend when I will get around to moving this PR forward, thanks for the suggestion

[radeusgd]

I just think that maybe function may be a more universal name here?

method fits well for Type.foo methods. But internal helper functions e.g.:

foo x =
    go i = ...
    go 0

are not really _method_s, are they?

So maybe

expected the result of `plusChecked` function to be Integer, but got Text

?

[Akirathan]

I don't know. I thought that everything function-like in Enso is just called method.

[radeusgd]

I did

expected the result of `plusChecked` to be Integer, but got Text

avoiding the method/function controversy.

IMO it is readable.