Bogus errors/warnings on Num literals

[mouse07410]

Your environment

• MacOS Monterey 12.6
• Xcode-14
• GHC-9.2.4 (also, 9.0.2, 9.4.1)
• Cabal-3.8.1.0
• HLS built from this master via ghcup compile hls --git-ref master --ghc 9.2.4
• hlint v3.3.6
• VS Code with Haskell for VIsual Studio Code v2.2.1
• haskell-linter v0.0.6 (an extension to use hlint in vscode)

hie.yaml file:

cradle:
  cabal:
    - path: "src"
      component: "lib:stepic-tests"

    - path: "app/Main.hs"
      component: "stepic-tests:exe:stepic-tests-exe"

    - path: "app/Paths_stepic_tests.hs"
      component: "stepic-tests:exe:stepic-tests-exe"

    - path: "test"
      component: "stepic-tests:test:stepic-tests-test"

    - path: "app/MaybeDemo.hs"
      component: "stepic-tests:exe:maybe-demo"

    - path: "app/Paths_stepic_tests.hs"
      component: "stepic-tests:exe:maybe-demo"

Steps to reproduce and Actual behavior

Open a .hs file in VS Code that contains integer literals, such as the following:

main :: IO ()
main = print $ nextPosN [1] (-1) (\x ->  sum x < 7)

nextPosN :: [Int] -> Int -> ([Int] -> Bool) -> [[Int]]
nextPosN = undefined

and observe the error (warning, actually):

No instance for (Num [Int]) arising from the literal ‘1’
• In the expression: 1
  In the first argument of ‘nextPosN’, namely ‘[1]’
  In the second argument of ‘($)’, namely
    ‘nextPosN [1] (- 1) (\ x -> sum x < 7)’

Closely related to it is this (GitHub appears to stop allowing uploading screenshot (PNG) images):

Quick Fix...
Convert 1 into 0x1
Convert 1 into 0o1
Convert 1 into 1.0e0 (needs extension: NumDecimals)

Restarting HLS does not help. Restarting VS Code removes this bogus report, at least for a while.

Expected behaviour

Not to be told to convert 1 into 0x1, to begin with. ;-)

More importantly, not to be told that there's No instance for (Num [Int]) arising from the literal '1'

[kokobd]

I can reproduce this only if [1] is changed to 1. See the screenshot below:

You can modify the [1] to something like [123], and see if the error message changes. If not, maybe HLS just hangs (it's a known problem, but I guess no one has a clue)

As for the quickfix, I suspect we are incorrectly using "quickfix" instead of "refactor" in these code actions. This need to be fixed.

[drsooch]

I'd have to look back at why I chose quickfix. I think it was originally refactor, and there was a semantic reason for the change

[mouse07410]

As for the quickfix, I suspect we are incorrectly using "quickfix" instead of "refactor" in these code actions. This need to be fixed.

Frankly, this is not the biggest concern of mine. HLS finds something in the code that could be "rephrased", it lists it's proposals, and offers to change the code automatically by itself.

It's less important to me whether it calls this "Quick Fix" (implying that it would be better to apply the change), or "Refactor" (conveying the impression that the code is fine even without appying the change).

[mouse07410]

I've upgraded hlint to v3.4.1 (and built it with GHC-9.2.4). The message

No instance for (Num [Int]) arising from the literal ‘1’
.  .  .

is no longer shown (so far, at least ;)).

However, this annoying prompt continues:

Quick Fix...
Convert 1 into 0x1
Convert 1 into 0o1
Convert 1 into 1.0e0 (needs extension: NumDecimals)

It's possible that I lack understanding of the language - but why on Earth would it want me to change 1 to 0x1 ? Especially since there's only "Quick Fix" popup, with no explanation of what it think may be wrong with the current code?

[kokobd]

but why on Earth would it want me to change 1 to 0x1 ?

They are useful refactoring actions. For example if I want to change the number format, but don't remember the exact syntax, then I can simply press cmd+. and choose from them.

The best we can do is to tell the LSP client that these are "refactor"s, other than quickfix. When hovering your pointer on the error, it will show "no quickfixes". But when pressing cmd+. it will still show these actions, as VSCode doesn't distinguish them in this case.

[mouse07410]

I can simply press cmd . and choose from them . . .

Speaking of which - now, with HLS-1.8.0.0 released, does it work with GHC-9.4.2?

The best we can do is to tell the LSP client that these are "refactor"s, other than quickfix.

Yes, now I see that it would be a good idea to distinguish. Currently, these "refactor"s show up with "yellow light-bulb", is it supposed to be so?

When hovering your pointer on the error, it will show "no quickfixes".

But it often does show quickfixes, at least for the errors HLS can figure how to fix! So far, only with GHC-9.4.2 it consistently did not...? Or do I misunderstand what you're saying?

[kokobd]

@mouse07410

I can simply press cmd . and choose from them . . .

Speaking of which - now, with HLS-1.8.0.0 released, does it work with GHC-9.4.2?

I'm on GHC-9.2 and it's working. It should work for GHC-9.4 too. You may give it a try.

When hovering your pointer on the error, it will show "no quickfixes".

But it often does show quickfixes, at least for the errors HLS can figure how to fix! So far, only with GHC-9.4.2 it consistently did not...? Or do I misunderstand what you're saying?

The alternate-number actions are NOT quickfixes semantically, but they are marked as quickfixes incorrectly now. We will change them to "refactor"s, so that they will no longer be shown up as quickfixes.

[mouse07410]

The alternate-number actions are NOT quickfixes semantically, but they are marked as quickfixes incorrectly now.

Is there any way to configure HLS (e.g., via VS Code settings.json) to ignore these actions? I'm sure they are useful to somebody, but I don't care to be informed that I can represent "1" as "0x1".

[drsooch]

haskell.plugin.alternateNumberFormat.globalOn: false