1. 22 Feb, 2020 1 commit
    • Vladislav Zavialov's avatar
      Parser API annotations: RealSrcLoc · be7068a6
      Vladislav Zavialov authored
      During parsing, GHC collects lexical information about AST nodes and
      stores it in a map. It is needed to faithfully restore original source
      code, e.g. compare these expressions:
      
      	a =  b
      	a  = b
      
      The position of the equality sign is not recorded in the AST, so it must
      be stored elsewhere.
      
      This system is described in Note [Api annotations].
      
      Before this patch, the mapping was represented by:
      
      	Map (SrcSpan, AnnKeywordId) SrcSpan
      
      After this patch, the mapping is represented by:
      
      	Map (RealSrcSpan, AnnKeywordId) RealSrcSpan
      
      The motivation behind this change is to avoid using the Ord SrcSpan
      instance (required by Map here), as it interferes with #17632 (see the
      discussion there).
      
      SrcSpan is isomorphic to  Either String RealSrcSpan,  but we shouldn't
      use those strings as Map keys. Those strings are intended as hints to
      the user, e.g. "<interactive>" or "<compiler-generated code>", so they
      are not a valid way to identify nodes in the source code.
      be7068a6
  2. 27 Jan, 2019 1 commit
    • Alan Zimmerman's avatar
      check-api-annotations checks for annotation preceding its span · 3cf12e60
      Alan Zimmerman authored
      For an API annotation to be useful, it must not occur before the span
      it is enclosed in.
      
      So, for check-api-annotation output, a line such as
      
      ((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]),
      
      should be flagged as an error, as the AnnOpenP location of 3:21
      precedes its enclosing span of 3:22-26.
      
      This patch does this.
      
      Closes #16217
      3cf12e60
  3. 26 Jan, 2017 1 commit
    • Alan Zimmerman's avatar
      Make type import/export API Annotation friendly · 0d1cb157
      Alan Zimmerman authored
      Summary:
      At the moment an export of the form
      
         type C(..)
      
      is parsed by the rule
      
      ```
        |  'type' oqtycon           {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2)))
                                           [mj AnnType $1,mj AnnVal $2] }
      ```
      
      This means that the origiinal oqtycon loses its location which is then retained
      in the AnnVal annotation.
      
      The problem is if the oqtycon has its own annotations, these get lost.
      
      e.g. in
      
        type (?)(..)
      
      the parens annotations for (?) get lost.
      
      This patch adds a wrapper around the name in the IE type to
      
      (a) provide a distinct location for the adornment annotation and
      
      (b) identify the specific adornment, for use in the pretty printer rather than
      occName magic.
      
      Updates haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: mpickering, dfeuer, bgamari, austin
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3016
      
      GHC Trac Issues: #13163
      0d1cb157