Expose the exhaustive list of hints

[sir4ur0n]

Hi,

First off, thank you for this linter, it's really useful for both my personal and professional projects! It helps me both keeping my code clean and learning new things.

I was wondering if there's a (ideally easy) way to extract the exhaustive list of hints that Hlint can return?

My use case: I'm maintaining a Sonar plugin for Haskell which needs to have at compile time the exhaustive list of lint rules (they must be packaged as XML inside the plugin JAR).

While I could browse all your code and list them manually, would you have any way to ease (ideally automate based on an Hlint version) this automation please?

I don't mind having to write a converter from whatever structure (JSON / XML / you name it) to my actual Sonar XML structure.

Thanks in advance and sorry if there's already such a thing! I hoped to be able to use the generation of hlint.yaml but unfortunately this is not what I expected.

Information I need for each lint rule:

• Technical name (a.k.a. "Key name" in Sonar), e.g. Use second (field hint)
• Display name. Given your hints are already pretty, I can reuse the same here.
• Description (ideally in HTML format, but anything would do)
• Severity (same as your severity field)
• Type (possible values in Sonar are CODE_SMELL | BUG | VULNERABILITY. I can work out a mapping from Hlint decl field I guess.

I would really appreciate if you could provide me with anything to help this project.

Thank you!

[ndmitchell]

See #562 which has a lot of overlap to this. For type, HLint only gives CODE_SMELL, so that's easy enough. For description, would an example be sufficient?

[sir4ur0n]

Thanks for your answers!

In case it's possible to improve things, an example would be great. Maybe also explain why something is bad (e.g. for performance / readability) but this would be bonus!

I started toying with hlint test --verbose and removing noise (like file path), some things don't look possible to convert into rules:

Error: Use bad
Found:
  readFile
Perhaps:
  bad

Error: Use bad
Found:
  Prelude2.readFile
Perhaps:
  bad

Error: Use Int32
Found:
  32 :: Int
Perhaps:
  32 :: Int32

Error: Use after
Found:
  before 12
Perhaps:
  after 12

I guess these are test values? I'm not sure anything can be extracted from it.

Some look good on the description (which is also the technical name hint from Hlint reports, if I'm not mistaken?):

Warning: Redundant id
Found:
  id 12
Perhaps:
  12

The Found/Perhaps part could be interpreted as a counter-example, this would fit for many rules.

I see the first word is Warning | Error | Suggestion, I guess this would be the severity field of Sonar?

As for the type, I think for a first version, it's cool to flag all rules as CODE_SMELL.

I also find duplicates:

Suggestion: Use forM
Found:
  flip mapM
Perhaps:
  Control.Monad.forM

Suggestion: Use forM
Found:
  flip mapM
Perhaps:
  Control.Monad.forM

Suggestion: Use forM
Found:
  flip mapM
Perhaps:
  CM.forM

I could filter on the technical name (e.g. Use forM) and keep only the first Found/Perhaps example...

That being said, would you mind explaining why this is hard to build an exhaustive list of Hlint rules? Is there anything a newbie/intermediate in Haskell could do/contribute to improve the situation? (I won't get offended if you reply "Nope, it's too complicated for you", no worries 😄 ).

Again, thanks for the help!

[ndmitchell]

I don't know why things are bad for each hint (I don't record it), but it's pretty much always readability.

Correct, things like "Use bad" are test values. I've eliminated them - just pushed.

The found/perhaps is indeed an example of something that triggers.

Error/Warning/Hint are reasonable for severity.

There are definitely duplicates, do dedupe them.

It's hard to build an exhaustive list of hints because they are functions that take expressions and returns hints, so it's not like there is a function for each hint. That said, I suspect that anything that isn't tested is broken, so hopefully we can get close to an exhaustive list with the test approach.