#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Comment (by simonpj): (I wrote this comment yesterday, but it has disappeared. Sigh.) Edsko, putting a special case in `rnLExpr` is a bit undesirable because: * It makes `rnLExpr` more than a dispactch to `rnExpr` * It means that `rnExpr` will never see a `HsQuasiQuoteE`, so it is "missing a case"; there's an invariant that the `HsQuasiQuoteE` case never occurs * It's fragile, because there might be ''other'' calls to `rnExpr` that don't satisfy that invariant. Here's an alternative. Replace {{{ rnExpr (HsQuasiQuoteE qq) = runQuasiQuoteExpr qq `thenM` \ (L _ expr') -> rnExpr expr' }}} with {{{ rnExpr (HsQuasiQuoteE qq) = runQuasiQuoteExpr qq `thenM` \ lexpr' -> rnExpr (HsPar lexpr') }}} Here I'm wrapping the returned expression in parens (which is probably a reasonable idea if we ever want to display the result of expanding quasiquotes), and that makes the types work out ok. The location on `lexpr'` will correctly be handled by the call to `rnLExpr` in the `HsPar` case of `rnExpr`. Would that work? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7918#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler