Skip to content

Completions can insert redundant imports #2270

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

Open
pepeiborra opened this issue Oct 10, 2021 · 1 comment
Open

Completions can insert redundant imports #2270

pepeiborra opened this issue Oct 10, 2021 · 1 comment
Labels

Comments

@pepeiborra
Copy link
Collaborator

pepeiborra commented Oct 10, 2021

In 1.4.0 we introduced completions for all local identifiers in the project. These completions automatically insert missing imports. It turns out that we don't verify whether the imports are actually missing, leading to some problems:

  1. Redundant imports, if the import already exists
  2. Conflicting import, if it's a redundant import that conflicts with something that already exists
  3. Circular imports, if the completed identifier is defined in the module being edited

All the above are painful, but 2 and 3 are specially annoying.

The solution for this would be:

  • for 1, to perform an isNeeded check in the command that inserts the new import.
  • for 3, to verify that the inserted module and the current module are different
  • 2 is a bug in the ordering of the completion suggestions. For example the user could legitimally want to use ByteString from Data.ByteString.Lazy even if Data.ByteString is already imported. The bug is in suggesting the non-imported completion before the imported one.
mergify bot pushed a commit that referenced this issue Nov 16, 2021
* Clean up previous entries in the exports map when updating it

* Add typeText for local completions of type/class declarations

helps with #2270

* add typeText for all local completions

* fix test

Co-authored-by: Javier Neira <atreyu.bbb@gmail.com>
@michaelpj
Copy link
Collaborator

It looks like this got partially fixed, but it seems like point 3 at least is still a problem.

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

No branches or pull requests

3 participants