Do not show internal hole names

[serras]

Fixes #847

This PR solves both problems:

• It contains a regular expression to catch internal names for holes /_[^_]*_.....?/ and rewrite them to _,
• It ensures that "no location info" is not shown by filtering out "unhelpful locations"

[serras]

If this PR gets accepted, may I ask to add the corresponding tag to count it towards my Hacktoberfest goal?

Maintainers of the repository can add the "hacktoberfest" topic to their repository if they wish to participate. Alternatively, an individual PR can be opted-in with a maintainer adding the "hacktoberfest-accepted" label to the PR.

[wz1000]

I'm not sure this is the best way to go about this. id __foo_bar_baz = __foo_bar_baz is a perfectly valid definition.

GHC already pretty prints these nicely in error messages. There must be some way to twiddle DynFlags to achieve the same effect.

[pepeiborra]

If this PR gets accepted, may I ask to add the corresponding tag to count it towards my Hacktoberfest goal?

Maintainers of the repository can add the "hacktoberfest" topic to their repository if they wish to participate. Alternatively, an individual PR can be opted-in with a maintainer adding the "hacktoberfest-accepted" label to the PR.

This is done, I have added the topic

[alanz]

I think the -dsuppress-uniques flag does this. Opt_SuppressUniques.

[serras]

@wz1000 you are completely right. I found another way to do this, but first I want to check @alanz's suggestion.

[serras]

I am very puzzled, the tests seem to break randomly on this part:

f = (:|):                                                                                         FAIL (0.82s)
  test/exe/Main.hs:3520:
  Found no matching actions for "import Data.List.NonEmpty (NonEmpty((:|)))" in []
f :: Natural:                                                                                     FAIL (0.80s)
  test/exe/Main.hs:3520:
  Found no matching actions for "import Numeric.Natural (Natural)" in []

However, in the previous push 8.10 broke, and now 8.8 breaks.

@pepeiborra @wz1000 @jneira (maybe somebody else) could you help me debugging this? Thanks in advance :)

[serras]

By the way, @alanz's approach of using SuppressUniques did the job, and now holes are shown with their original names :)

[pepeiborra]

I am very puzzled, the tests seem to break randomly on this part:

f = (:|):                                                                                         FAIL (0.82s)
  test/exe/Main.hs:3520:
  Found no matching actions for "import Data.List.NonEmpty (NonEmpty((:|)))" in []
f :: Natural:                                                                                     FAIL (0.80s)
  test/exe/Main.hs:3520:
  Found no matching actions for "import Numeric.Natural (Natural)" in []

However, in the previous push 8.10 broke, and now 8.8 breaks.

@pepeiborra @wz1000 @jneira (maybe somebody else) could you help me debugging this? Thanks in advance :)

I think this happens because you added a hole to the GotoHover module which is used by these tests. GHC is quite slow at providing fill hole suggestions, and these tests are probably not waiting for diagnostics before asking for code actions (should they?). Either fix the tests to wait for diagnostics, or put the hole somewhere else.

[serras]

I managed to make the import suggestions work by removing GotoHover from the cradle. Although there is a commit adding more time to those tests, it has been reverted later on.

[alanz]

Times in tests make me very nervous. Shouldn't you just wait for the diagnostics to get published?

[pepeiborra]

these tests are checking for import suggestions, which rely either on the full project being checked (for local imports) or the transitive build-depends being loaded (for package imports). Both actions happen asynchronously and ghcide does not send any notification that can be used to wait currently. Would be easy to fix but certainly doesn't belong in this PR

[pepeiborra]

Thanks!