hlint
hlint copied to clipboard
ndmitchell
hlint: Unknown extension: 'Trustworthy'
We generate HLint step in haskell-ci which takes whatever default-extensions are in package. Sometimes Trustworthy and Safe are part of them.
I think HLint should recognize Unsafe, Trustworthy and Safe, even it doesn't do anything with them.
Thanks for letting me know. Definitely a bug. We get the extensions by calling readExtension from @shayne-fletcher's ghc-lib-parser-ex. There is no Safe value in the Extension data type it produces. I wonder if there should be some kind of function in that package which can also read an extension, or one of those pseudo-extensions that aren't in GHC's extension type? I'd rather HLint was isolated from what those were, but I can add if there is necessary.
Yup, they seem not to be - https://github.com/ndmitchell/hlint/issues/961#issuecomment-623017720
And it seems you've already fixed this once. I wonder what happened for a regression to occur :thinking:
IIRC -XSafe and friends are parsed into https://hackage.haskell.org/package/ghc-8.10.2/docs/GHC.html#t:SafeHaskellMode by cli, somewhat similarly as -XHaskell2010 isn't an extension but a Language
Thanks @googleson78 for remembering the issue! Very useful context. So the previous issue was if you wrote {-# LANGUAGE Safe #-} at the top of a file we crashed. This issue is about adding -XSafe on the command line. The fix in #961 was to just ignore any extensions we didn't know about - that might be a perfectly reasonable thing to do here too. If you pass -XScala should HLint give an error or not?
@ndmitchell If warning is an option, it would be fine with me. (= don't fail, but don't ignore silently either).
Even if we did warnings for unknown extensions, I'd want -XSafe etc to not trigger that warning. And I'm a little wary of warnings as they are usually just ignored, and HLint currently has no "warnings" other than those produced as lints.
Agreed. It would be great however that HLint-3.next warned about LinearTypes if it doesn't yet know about it, rather then only failing with parse error. (EDIT: removed nonsense).
So, @ndmitchell anything for me to do here? If so, perhaps a ticket if you please!
I think for extensions in files, HLint is right to ignore it. The extension is being given to GHC, and HLint is snooping on it. Great if HLint can find meaningful information, but if not, it should presume GHC and the user have it under control.
For extensions passed to HLint, we could either error ("Unknown extension"), or ignore. Erroring ensures people don't accidentally type -XGADPs. But means people who generate their HLint flags from extensions get errors on -XLinearTypes. My inclination is to say we error on those we don't know about, as that's what we do now.
That means we need a way to parse "pseudo extensions" from GHC, things that are extension but that readExtension doesn't work for. As far as I'm aware, that's Trustworth, Safe and Unsafe. So, maybe we need:
data PseudoExtension = Safe | Unsafe | Trustworthy
readPseudoExtension :: String -> Maybe PseudoExtension
And if we need that, having it in ghc-lib-parser-ex seems like a reasonable place to put it. Thoughts? (Not quite as far as a ticket @shayne-fletcher - more a thought of "is this the way to go", and if everyone agrees, then a ticket)