<div dir="ltr"><div><div><div><div>I aplogise for the following long post on Api Annotations.<br><br></div>They are a new feature, and allow a whole class of tools to become much simpler. The interest in this technology can be seen in the strong support Matt Pickering's proposal for GSOC achieved, and that it was accepted. This project is a good showcase for the annotations, as it should allow the hints from HLint to be directly applied to the source code.<br><br></div>This technology can only be useful when it is generally available, which means being baked in to the compiler. We came really close to getting it all together for 7.10.1, but unfortunately some issues slipped through. These were picked up when Matt Pickering ran the ghc-exactrpint utliity over most of hackage, and found the remaining ones. The fixes for these are now all queued up in trac/phab with patches. If they do not go in to 7.10.2 it means waiting for 7.12 to be in general use before the tooling built from this can be used widely.<br><br></div><div>The patches themselves do not change the operation of the compiler, merely re-arrange things slightly in the parsing stage, to make sure all the annotations make it through to the final ParsedSource.  The two most intrusive ones are<br><br></div><div>D840, which introduces new parser productions to correct a pre-existing error where `'[]` was parsed as a <tt class="">`HsTyVar`</tt> rather than a<tt class=""> `HsExplicitListTy</tt>`. These have different annotations so it is a problem; and<br></div><br></div>D836, which preserves the parsed `HsForAllTy` structure, including any nested `HsParTy` wrappers. This results in the original flattening code being moved out of `RdrHsSyn` into the renamer and typechecker, but does not change any of the operations.<br><br><div>I know this places a huge burden on Austin in particular, because it requires a lot of merge operations from the number of patches. The only way I can propose to ease this is to submit a mega-patch with all the changes, which can be applied at once, once the individual ones are reviewed and found acceptable (with whatever fixes are required).<br><br>The full list of Trac tickers / Phab patches follows below.<br><br></div><div>Regards<br></div><div>  Alan<br><br>---------------------------------------------------------<br>10207 - parser: ParStmt has incorrect SrcSpan<br>        D803 (landed 7.10.2)<br><br>10214 - parser: TransStmt has incorrect SrcSpan<br>        D806 (landed 7.10.2)<br><br>---<br>10209 - parser: opt_kind_sig has incorrect SrcSpan<br>        D813 (landed master, scheduled 7.10.2)<br><br>10255 - API Annotations : ExprWithTySig processing discards annotated spans<br>        D823 (landed master, scheduled 7.10.2)<br><br>---<br><br>10357 - ApiAnnotations : pquals production adds AnnVbar in the wrong place<br>        D869<br><br>10358 - ApiAnnotations : PatBind gives wrong SrcSpan for the pattern.<br>        D873<br><br>10254 - parser : the API annotation on opt_sig is being discarded<br>        D822 (landed master)<br><br>10256 - parser: API Annotations : guardquals1 does not annotate commas properly<br>        D818 (landed master)<br><br>10268 - ApiAnnotations : quoted type variables missing leading quote<br>        D825. (Accepted Austin) Depends D840/#10299 <br><br>10269 - ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses<br>        D832 (Accepted Austin)<br>        Note: Potentially keep HsPar as an alternate?<br><br>10277 - ApiAnnotations : lexer discards comment close in nested comment<br>        D829 (landed master)<br><br>10280 - ApiAnnotations : AnnComma missing in TupleSection<br>        D834 (Accepted Austin)<br><br>10287 - ApiAnnotations : BooleanFormula construction discards original<br>        D837. Partial fix. Full fix by locating BooleanFormula properly.<br><br>10307 - Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected<br>        D842<br><br>10309 - ApiAnnotations : mkGadtDecl discards annotations for HsFunTy<br>        D848<br><br>10312 - ApiAnnotations: misplaced AnnComma for squals production <br>        D846 (accepted Austin)<br><br>10299 - D840: Correct parsing of lifted empty list constructor<br>        D840<br><br>--- The next four are all addressed by D836<br>10315 - ApiAnnotations : Empty context loses annotations<br>        D855 retired, fixed by 10354/D836<br>10354 - ApiAnnotations : parens around a context with wildcard loses annotations<br>        D868 - no, superseded by D836<br>10363 - ApiAnnotations : HsForAllTy discards parens<br>        D836<br>10278 - ApiAnnotations : Nested forall loses forall annotation<br>        D836 (old/alternate D833)<br><br>---------------------------------------------------------<br></div><div><br><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 5, 2015 at 1:16 PM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just to be clear, the issue is this<br>
<br>
* For whom is 7.10.2 mission-critical?<br>
* And with what patches? (give specific tickets)<br>
* And by what date?<br>
<br>
The only reason to make a release is because someone is stalled, or seriously inconvenienced, unit it happens.  Otherwise we should wait.  So: "+1" doesn't give enough information.  Of course, the sooner the better, the more bugs fixed the better.<br>
<br>
You might say "I'm waiting for API Annotations; but I'm under no time pressure".  Or "My whole business is stalled pending a fix to Trac #xxx" or whatever.<br>
<br>
The whole API annotations thing is a special case.  We usually make NO api changes in a patch-level release.  But the API annotations stuff is brand new, and apparently most of the fixes depend on API changes.  So I think we are going to let them sneak in.  Do we have a comprehensive list, in Trac tickets of all the patches that are sought?<br>
<br>
The canonical list is <a href="https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2</a><br>
Only patches that are listed as "merge" or "patch" are even being considered.  If you have something you care about that is not in that state, can you cause it to be in that state?<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888"><br>
Simon<br>
</font></span><span class="im HOEnZb"><br>
|  -----Original Message-----<br>
|  From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a>] On Behalf Of<br>
</span><div class="HOEnZb"><div class="h5">|  Matthew Pickering<br>
|  Sent: 05 May 2015 12:09<br>
|  To: Alan & Kim Zimmerman<br>
|  Cc: <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
|  Subject: Re: release timing<br>
|<br>
|  +1 for the API Annotations patches.<br>
|<br>
|  On Tue, May 5, 2015 at 11:26 AM, Alan & Kim Zimmerman<br>
|  <<a href="mailto:alan.zimm@gmail.com">alan.zimm@gmail.com</a>> wrote:<br>
|  > I'd love to see the various queued API Annotations diffs go in.<br>
|  ><br>
|  > Alan<br>
|  ><br>
|  > On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>><br>
|  wrote:<br>
|  >><br>
|  >> I'd love to see GHC 7.10.2 once this haddock issue is fixed:<br>
|  >> <a href="https://github.com/haskell/haddock/issues/385" target="_blank">https://github.com/haskell/haddock/issues/385</a><br>
|  >><br>
|  >> On 05/05/15 13:08, Simon Peyton Jones wrote:<br>
|  >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC<br>
|  7.10.2!<br>
|  >> > Crazy, I know, and who knows if we can pull it off....<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > Good plan!<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > In Austin’s last GHC Weekly News we asked if anyone had any<br>
|  >> > constraints on the release of GHC 7.10.2.  So far as I know, no<br>
|  one<br>
|  >> > replied.  *So the current status is that we’ll hold it until<br>
|  >> > someone says “getting<br>
|  >> > 7.10.2 out really matters to me”.*  Other things being equal, the<br>
|  >> > longer we wait, the more fixes will be in.<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > But does anything stand in the way of pressing the button on the<br>
|  HP<br>
|  >> > build, so that you have a HP 7.10.2 ready to go?  You can always<br>
|  >> > press the button again if/when further fixes go in.<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > Simon<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > *From:*ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a>] *On Behalf<br>
|  Of<br>
|  >> > *Mark Lentczner<br>
|  >> > *Sent:* 02 May 2015 01:57<br>
|  >> > *To:* <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
|  >> > *Subject:* release timing<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > I'm wondering if ghc 7.10.2 has a rough time table yet?<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > This time 'round I'd like to do a HP 7.10.2 concurrent with GHC<br>
|  7.10.2!<br>
|  >> > Crazy, I know, and who knows if we can pull it off....<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > But I imagine it is about 3 or 4 week cycle for HP at this point<br>
|  >> > (still)... so a few weeks' "heads up" would be good. Thoughts?<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > - Mark<br>
|  >> ><br>
|  >> ><br>
|  >> ><br>
|  >> > _______________________________________________<br>
|  >> > ghc-devs mailing list<br>
|  >> > <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
|  >> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
|  >> ><br>
|  >><br>
|  >><br>
|  >><br>
|  >> _______________________________________________<br>
|  >> ghc-devs mailing list<br>
|  >> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
|  >> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
|  >><br>
|  ><br>
|  ><br>
|  > _______________________________________________<br>
|  > ghc-devs mailing list<br>
|  > <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
|  > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
|  ><br>
|  _______________________________________________<br>
|  ghc-devs mailing list<br>
|  <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
|  <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>