#8607: Invalid location reported for type constructors -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by goldfire): * owner: goldfire => Comment: So, I took a look at this, and it's ugly. The problem is that each `TyClDecl` can give rise to potentially many top-level things. Of these things, only the `TyCon`s are checked for validity, so we really only need location info for `TyCon`s. It's a little painful returning a `[Located TyThing]` when the `Located` bit applies to only one disjunct of `TyThing`. But, I was willing to deal with that. The real problem comes from the fact that one declaration can actually produce many `TyCon`s: a class with associated types. According to the validity checking code -- which checks all `TyCon`s, top-level and not -- we would need these associated type `TyCon`s to have correct locations. Unfortunately, there is no clean way to get good locations for associated types without polluting the code in `tcClassATs` and possibly `ClassATItem`, which is persisted within the `Class` datatype. Very yuck. Is all of this doable? Absolutely, but it would make Simon wish he had just stayed on holiday. So, I propose that, to fix this problem, we store location information ''in the `TyCon`''. This should be easy to get correct and easy to use. It would be cleaner than adding `Located` in various places throughout !TcTyClsDecls. But, it stores location information in a very Core-ish place, and I would rather consult with others before going ahead with this plan. There is precedent: `CoAxBranch`es store locations for similar reasons. But, of course, I was the chief person behind `CoAxBranch`es, and it's a little silly to use my own design decision as precedent. Thoughts? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8607#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler