-
-
Notifications
You must be signed in to change notification settings - Fork 808
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
Make compiler hint to import unqualified types/values #4304
base: main
Are you sure you want to change the base?
Conversation
The hints should be done now, although I don't if its possible to find the arity (suppose someone wrote |
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.
Thank you! I've added some comments inline, and snapshot tests will need to be added to test all the new paths through the code.
It would be great to also check the arity of the constructors. Suggesting a zero-arity Wibble
when it is being used in a way that takes 2 arguments would be unhelpful.
compiler-core/src/type_/error.rs
Outdated
if is_type { | ||
format!("Did you mean to import `{module}.{{type {name}}}`?") | ||
} else { | ||
format!("Did you mean to import `{module}.{{{name}}}`") |
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.
I don't want to encourage unqualified importing of values. Perhaps we should only make these suggestions for types and record constructors.
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.
Okay! Tying with my point below, we could write the "generic" value case as "Did you mean to reference module.{value}
" and, in case it isn't already imported, "Did you mean to import module
and reference module.{value}
". What do you think?
...tests/snapshots/gleam_core__type___tests__imports__imported_constructor_instead_of_type.snap
Outdated
Show resolved
Hide resolved
compiler-core/src/error.rs
Outdated
@@ -2326,7 +2331,7 @@ but no type in scope with that name." | |||
Diagnostic { | |||
title: "Unknown variable".into(), | |||
text, | |||
hint: None, | |||
hint: suggestions.first().map(|suggestion| suggestion.suggestion(name, false)), |
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.
There's a vector of suggestions, but only the first one is used. Seems like only one should be given in that case.
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.
I thought this was fine, as that is what the current code for module suggestions does. Anyway, I'll change it!
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.
Actually, having a vector of suggestions allows the LS to give all possible quick fixes when a code action to do so is done (I have one basically ready, will do a PR after this one is pushed)
The code should now consider arity, but it is an |
Hey @lpil, I've answered some of your questions, waiting on clarifications! |
I have implemented the code actions locally. Should I push them to this PR or wait for a future one? |
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.
Thank you! Looking good. I've left some comments inline, and the tests still need to be added for each possible path through the code.
...tests/snapshots/gleam_core__type___tests__imports__imported_constructor_instead_of_type.snap
Outdated
Show resolved
Hide resolved
...src/type_/tests/snapshots/gleam_core__type___tests__errors__same_imports_multiple_times.snap
Outdated
Show resolved
Hide resolved
…import suggestions
@lpil, I think I have addressed all of your points! Right now I just need to comment and write tests, and I'm waiting on some clarifications. |
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.
Thank you
Should be all done now! |
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.
Thank you! Nearly there! Few small things around the wording
compiler-core/src/type_/error.rs
Outdated
match self { | ||
ModuleSuggestion::Importable(module) => match layer { | ||
Layer::Type => format!("Did you mean to import `{module}.{{type {name}}}`?"), | ||
Layer::Value => format!("Did you mean to import `{module}.{{{name}}}`?"), |
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.
This still has the confusing syntax that is easy to misread. Perhaps it can avoid using Gleam syntax altogether and copy the format used in the existing function.
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.
What about "Did you mean to import module.name
"?
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.
That's not Gleam syntax either. It should either be Gleam syntax, or it should not look like code.
Let's use a sentence without any code-like bits, similar to the existing module error suggestion
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.
What do you think about "Did you mean to import {module}
and add {name}
as a unqualified import" then?
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.
I was thinking something like "did you mean to import the {value}
value from the {module}
module?"
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.
Oh, this is great! Thanks for the suggestion!
Now it should be ready! Also, the way I've refactored, it allows for the normal module suggestion to consider arity in the future |
This PR closes #4297
Currently the way it decides which module to hint is by preferring imported modules over importable ones, and sorting by name length.