I don't remember the details precisely, but I do know that the BufSpan was added to allow for reliable comparisons of SrcSpans in the presence of #line pragams. I've included Vlad, who is the resident expert on this aspect of locations.
My instinct is to lean against repurposing the existing slot just because it happens to fit, unless there is a semantic argument for why the Maybe BufSpan and the Anchor represent the same underlying concept. Richard > On Oct 28, 2021, at 5:18 PM, Alan & Kim Zimmerman <alan.z...@gmail.com> wrote: > > I have been updating the ghc-exactprint library for real world use cases on > the about to be released GHC 9.2.1, and realised I need to be able to put an > Anchor into every SrcSpan in the ParsedSource AST. > > I prepared !6854 to sort it out in master and turned to the problem of GHC > 9.2.1, where I had missed the boat. > > And then I discovered that we have SrcSpan defined as > > data SrcSpan = > RealSrcSpan !RealSrcSpan !(Maybe BufSpan) > | UnhelpfulSpan !UnhelpfulSpanReason > > and the (Maybe BufSpan) is only used for attaching haddock comments after > parsing. > > This means there is an isomorphism between the RealSrcSpan variant and an > Anchor, which I take advantage of with the code in [1], by using the Maybe to > encode the AnchorOperation and the BufSpan to encode the DeltaPos. > > And it struck me that perhaps we should make this a more official approach. > The only problem is the detail of the BufSpan, to be able to play both roles > cleanly. > > Alan > > [1] https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635 > <https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
