-
-
Notifications
You must be signed in to change notification settings - Fork 782
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
Use local module appropriate names when printing types in warnings #4164
Comments
todo
produce incorrectly typed hintstodo
produces incorrectly typed hints
Hello! I think this may not be a bug and that it's that these warnings do not display types in the context of the local module, but they happen to use the same names that you are using. If I change the names it'll be more clear: pub fn curry(f: fn(t1, t2) -> t3) -> fn(t1) -> fn(t2) -> t3 {
fn(a: t1) { todo }
}
That said, there could be something I'm missing. Could you share the code needed to reproduce what you've got please 🙏 |
Wow you are absolutely right! Thanks for the speedy response :) This threw me off guard, never would have expected it... As I'm teaching a course involving Gleam, I will take this into account and use type variables outside the first letters of the alphabet. I think the hint could be improved to display the type variables that are actually used or use a notation such as Do you want me to close this issue or change it to a feature request? |
I agree, it could be made more clear. I think the ideal would be for the warnings to print types using the appropriate local syntax for a function! |
todo
produces incorrectly typed hints
Yes I think when making error messages context-aware, I forgot to make warning messages context-aware |
The following code suggests incorrect type for
todo
producing a warning which suggests
which is obviously incorrect as
todo
should be replaced with a function of typefn(b) -> c
.Investigation
I have been digging in
/compiler-core/_type/pretty.rs
and added tests:and
which both pass, so I guess the issue is not related to the pretty printer but rather happens somewhere in the type system.
Testing
I added the following snap test which currently fails
Further questions
The issue might be present with
panic
as well as the code follows similar logic astodo
's code.The text was updated successfully, but these errors were encountered: