Make it easier to debug fixity issues

[brandonchinn178]

In fourmolu/fourmolu#357 (comment), it took a bit before realizing that NoImplicitPrelude is causing Prelude operators from getting the correct fixity. Is there some way we can make debugging this easier, e.g. when --debug is turned on? Perhaps when --debug is turned on, show warnings when operators from base are detected with different fixity info? I think base is an important enough package to special case this logic. Or perhaps show the warning if any operators have different fixity than in the Hackage fixity map? Since this would only show up with --debug, I think being a bit noisy with false positives is better than otherwise

[amesgen]

Perhaps when --debug is turned on, show warnings when operators from base are detected with different fixity info?

This (or something similar, maybe hardcoding more "common" packages or even all packages) sounds reasonable to me, and seems to have a good power-to-weight ratio a priori.

If complexity were not an issue, it would be fancy to output an "inference path" for every operator that shows how Ormolu/Fourmolu came to chose the specific fixity.

---

Eventually, it would be very nice to have a more principled way to infer fixity info; but apart from relying fully on GHC (which would bring its own bag of problems, i.e. you can only format code that passes at least the renamer phase), I don't see many local improvements of the current approach 🤔

[Lucus16]

I'm running into this as well, I have a large code base using a custom prelude and manually writing down the fixity of each operator we use is some work, but figuring out the full list of operators we use is much harder still. It would help if there was an option that would cause ormolu to fail if it encountered an operator for which it does not know the fixity. That would make it easy to ensure we have defined all the fixities we need.