`-fno-max-refinement-hole-fits` is ignored

[Aster89]

Your environment

Which OS do you use? ArchLinux

Which version of GHC do you use and how did you install it? 9.14.1 GHCup

How is your project built (alternative: link to the project)? See below

Which LSP client (editor/plugin) do you use? Terminal Vim + YCM

Which version of HLS do you use and how did you install it? 2.14.0.0 via GHCup

Have you configured HLS in any way (especially: a hie.yaml file)? No

Steps to reproduce

cabal-version:   3.4
name:            app
version:         0.1.0.0
executable app
    main-is: Main.hs
    build-depends: base
    hs-source-dirs:   .
    default-language: GHC2024

packages: .
package *
  ghc-options: -fno-defer-typed-holes
with-compiler: ghc-9.14.1

-- This is just because to bring the number of valid holes to 7 (i.e. above the
-- default of 6)
fun :: Int -> [Int] -> [Int]
fun = _

main :: IO ()
main = do
  let x :: [Int] = _ (_ :: Int) (_ :: [Int])
  print x

Ask for diagnostics on the first _ on line 9. You'll get:

 • Found hole: _ :: Int -> [Int] -> [Int]
 • In the expression: _ (_ :: Int) (_ :: [Int])
   In a pattern binding: x :: [Int] = _ (_ :: Int) (_ :: [Int])
   In a stmt of a 'do' block:
     let x :: [Int] = _ (_ :: Int) (_ :: [Int])
 • Relevant bindings include
     main :: IO () (bound at /home/enrico/deleteme/app/Main.hs:8:1)
   Valid hole fits include
     fun
     (:)
     drop
     take
     (<$)
     mempty
     (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits)
   Valid refinement hole fits include
     ($!) _
     const _
     flip _
     curry _
     (!!) _
     id _
     (Some refinement hole fits suppressed; use -fmax-refinement-hole-fits=N or -fno-max-refinement-hole-fits) [GHC-88464]

revealing that the default of 6 for both -fmax-valid-hole-fits and -fmax-refinement-hole-fits causes some hole fits to be suppressed.

Now add this line

    ghc-options: -fmax-valid-hole-fits=20 -fmax-refinement-hole-fits=20

to the executable app stanza, reload HLS, and see the diagnostics again:

 • Found hole: _ :: Int -> [Int] -> [Int]
 • In the expression: _ (_ :: Int) (_ :: [Int])
   In a pattern binding: x :: [Int] = _ (_ :: Int) (_ :: [Int])
   In a stmt of a 'do' block:
     let x :: [Int] = _ (_ :: Int) (_ :: [Int])
 • Relevant bindings include
     main :: IO () (bound at /home/enrico/deleteme/app/Main.hs:8:1)
   Valid hole fits include
     fun
     (:)
     drop
     take
     (<$)
     mempty
     seq
   Valid refinement hole fits include
     ($!) _
     const _
     flip _
     curry _
     (!!) _
     scanl _
     scanr _
     ($) _
     return _
     pure _
     id _
     head _
     last _
     mconcat _ [GHC-88464]

revealing that all holes HLS is aware of are shown now.

One last time, change the added line to this:

    ghc-options: -fno-max-valid-hole-fits -fno-max-refinement-hole-fits

Expected behaviour

I would expect the same diagnostics as before.

Actual behaviour

The diagnostic you'll get, instead, is this:

 • Found hole: _ :: Int -> [Int] -> [Int]
 • In the expression: _ (_ :: Int) (_ :: [Int])
   In a pattern binding: x :: [Int] = _ (_ :: Int) (_ :: [Int])
   In a stmt of a 'do' block:
     let x :: [Int] = _ (_ :: Int) (_ :: [Int])
 • Relevant bindings include
     main :: IO () (bound at /home/enrico/deleteme/app/Main.hs:8:1)
   Valid hole fits include
     fun
     (:)
     drop
     take
     (<$)
     mempty
     seq
   Valid refinement hole fits include
     ($!) _
     const _
     flip _
     curry _
     (!!) _
     scanl _
     scanr _
     id _
     head _
     last _
     (Some refinement hole fits suppressed; use -fmax-refinement-hole-fits=N or -fno-max-refinement-hole-fits) [GHC-88464]

which reveals that the refinement mconcat _ is suppressed, meaning that -fno-max-refinement-hole-fits is in fact ignored.

Debug information

Not sure what else I can provide. Let me know.

[fendor]

see #4198 for the reason we limited the number of hole fits

[Aster89]

But -fmax-refinement-hole-fits=20 does its job (see in the example 14 holes are shown). So why shouldn't -fmax-refinement-hole-fits do as well?

The linked issue seem to have to do with the default value, not with the flags to change those options.