Handle module re-exports correctly when inferring fixity of operators
mrkkrp opened this issue · 1 comments
After #994 we are now more precise about fixities, but this comes with a problem that some users may perceive as a regression, and they would be right. Now that we infer fixities based on import sections, we need to be precise about what operators are imported and from where. #994 largely handles that decently enough, except for one important case—module re-exports. The Hoogle database that we use to scrap operator/fixity declaration provides zero information about module re-exports, which means that when someone imports e.g. Control.Lens, they can't expect the same results as when they import Control.Lens.Operators. I think this is serious enough to delay the release of 0.7.0.0 for now.
Perhaps we could switch to using Hackage index and parse it with the GHC parser. What's worse there is also the possibility of arbitrary operator re-export which would mean that we need to take into account import sections of the files we are sourcing our fixity information from.