Add to an error message to address issue #5722 #5830
Conversation
|
Thanks @dolio; could you add a transcript that demos the error message? And then good to go. |
| "signature does not specify the abilities used. It may also be from a\n", | ||
| "variable introduced by an ability match escaping its scope.", |
There was a problem hiding this comment.
One minor thing. Anytime you're editing error messages, it's a good opportunity to switch away from using hard linebreaks - hard linebreaks result in weird rendering depending on the user's terminal width. It's a bit of longstanding tech debt that the dynamic wrapping is used inconsistently in our error messages.
You can follow other examples in this file which use the pretty-printing library to get it to wrap dynamically based on the width of the terminal, using Pr.wrap, Pr.lines, etc.
I wouldn't necessarily hold up a PR just for this, but it's an example of "leave the code a bit nicer than you found it". :)
There was a problem hiding this comment.
Oh, great. I would have done this to begin with, but for some reason I thought we didn't do auto-wrapping.
There was a problem hiding this comment.
In retrospect, it wasn't that I thought we couldn't do wrapping. It's that I didn't understand how to use the wrapping combinator correctly (just on a single paragraph you want wrapped). So before when I tried to use it, it would crush my message into a single blob.
The message is now properly wrapped.
|
BTW, the transcript from #5825 will have the error message. It's the same error message regardless of how it gets triggered, because I don't think it's easy to tell the two cases apart. I think that's why the transcripts are failing. I forgot to re-run them and check in the new message. |
|
BTW, I have some other transcripts that change locally on rerun, but they don't have anything to do with what I changed here. Edit: I guess this has been fixed in a newer trunk than I forked from. |
This adjusts the error message from #5825 to address the situation in in #5722. The latter triggers the same failure in the type checker, but the reason is different. In this case it's just an ability match introducing a type variable that is not allowed to escape the scope, but will as written.