Someone should look into whether RebindableSyntax is the only cause of UnhelpfulSpans
As part of !3868, we have a bit of a new code provenance thing going on to replace tcl_in_gen_code and extend the environment in such a way as to account for code generated by deriving clauses as well. As part of this, there are a few open questions regarding SrcSpans, and especially UnhelpfulSpan.
In compiler/GHC/Tc/Utils/Monad.hs
, there is a function setSrcSpan
:
setSrcSpan :: SrcSpan -> TcRn a -> TcRn a
setSrcSpan (RealSrcSpan loc _) thing_inside =
updLclEnv (\env -> env { tcl_loc = loc, tcl_in_gen_code = False })
thing_inside
setSrcSpan loc@(UnhelpfulSpan _) thing_inside
-- See Note [Rebindable syntax and HsExpansion].
| isGeneratedSrcSpan loc =
updLclEnv (\env -> env { tcl_in_gen_code = True }) thing_inside
and note that
isGeneratedSrcSpan :: SrcSpan -> Bool
isGeneratedSrcSpan (UnhelpfulSpan UnhelpfulGenerated) = True
isGeneratedSrcSpan _ = False
So setSrcSpan
basically assumes that isGeneratedSrcSpan loc
means that the given SrcSpan
must have been generated by RebindableSyntax, and so sets the tcl_in_gen_code
flag. Note that any contained SrcSpan
s will set tcl_in_gen_code
back to False, which is generally appropriate for RebindableSyntax, but possibly not for any other sort of generated code.
It would be nice to know for sure that RebindableSyntax really is the only source of UnhelpfulSpan UnhelpfulGenerated
, and that the only way we'll see an UnhelpfulSpan is if RebindableSyntax makes one. (It also seems to be the case that wired-in things and interactive code will sometimes have UnhelpfulSpan, but I'm not sure if those are an important consideration.)
Should we have provenances at the TcLclEnv level for wired-in things and interactive code? Should we have information in the SrcSpans which indicates provenance (for things like deriving and TH in addition to rebindable syntax)? We couldn't, for example, determine at present that a particular bit of code was generated by deriving
only by looking at the SrcSpans.
It would be nice for someone more experienced with the way GHC is using these things to give this a look and see if any simplification or extension is in order.