Remove Strict from the language extensions used for code actions
#638
Conversation
|
I agree that the suggest extension logic is a bit flaky, it's the way it is until GHC gives us structured error messages (there are already 2 GHC proposals under way). Lowering the priority will help the 20% of cases where the suggestion is wrong, but unhelp the other 80% of cases where the suggestion is right. Based on my experience that Those functions come from the lsp-test package |
awesome!
Sounds good to me!
thanks! |
tek
force-pushed
the
deprioritize-suggest-extension
branch
from
39aea52 to
ab229a5
Compare
tek
changed the title
Strict from the language extensions used for code actions
|
@pepeiborra you fine with it like this? |
|
awesome! 🚀 |
| ghcExtensions = Map.fromList . map ( ( T.pack . flagSpecName ) &&& flagSpecFlag ) $ xFlags | ||
| ghcExtensions = Map.fromList . filter notStrictFlag . map ( ( T.pack . flagSpecName ) &&& flagSpecFlag ) $ xFlags | ||
| where | ||
| notStrictFlag (name, _) = name /= "Strict" |
There was a problem hiding this comment.
I'd add a link to the issue you initially raised here. It's one odd and unexpected exception, so having the backstory is always useful.
There was a problem hiding this comment.
@ndmitchell done!
there's no issue though, only this PR.
There was a problem hiding this comment.
Thanks - this PR is fine.
Since the code action for language extension suggestions uses substring matching, the presence of the literal name of an extension can trigger a false positive. `Strict` is an identifier that occurs frequently in imports, causing the extension to be suggested rather than the removal of a redundant import.
tek
force-pushed
the
deprioritize-suggest-extension
branch
from
ab229a5 to
bb4abdd
Compare
…askell/ghcide#638) Since the code action for language extension suggestions uses substring matching, the presence of the literal name of an extension can trigger a false positive. `Strict` is an identifier that occurs frequently in imports, causing the extension to be suggested rather than the removal of a redundant import.
…askell/ghcide#638) Since the code action for language extension suggestions uses substring matching, the presence of the literal name of an extension can trigger a false positive. `Strict` is an identifier that occurs frequently in imports, causing the extension to be suggested rather than the removal of a redundant import.
…askell/ghcide#638) Since the code action for language extension suggestions uses substring matching, the presence of the literal name of an extension can trigger a false positive. `Strict` is an identifier that occurs frequently in imports, causing the extension to be suggested rather than the removal of a redundant import.
This code action uses an unreliable heuristic, i.e. substring matching
for all existing language extensions.
The "quickfix" LSP action chooses an arbitrary code action from the
list, presumably the first in the list.
As an example, the redundant import
import Data.Map.Strictwill trigger the suggestion to add the language extension "Strict".
Moving this suggestion to the end of the list reduces the likelihood
for false positives.
Since selection of the quickfix action happens outside of ghcide, there's probably a better solution.
Any suggestions? A better workaround could be to check for the language extension's name's presence in the offending code.
I added a test but it fails and I don't see the definitions of
getCodeActionsandexecuteCodeAction. Some advice would be appreciated!