By the way - the correct URL for the review is: http://cr.openjdk.java.net/~attila/8067774/webrev.8u-dev/ <http://cr.openjdk.java.net/~attila/8067774/webrev.8u-dev/>
/M > On 18 Dec 2014, at 09:59, Marcus Lagergren <[email protected]> > wrote: > > You’re welcome! :-) We’re doing what we can to respond quickly, Guillaume. > > If you want to track the integration of the fix you can check the CR in JIRA > for updates. > > Regards > Marcus > >> On 17 Dec 2014, at 18:43, Guillaume Grossetie <[email protected]> wrote: >> >> Excellent news!! Thanks for this bugfix :) >> >> Le 17 déc. 2014 18:04, "Marcus Lagergren" <[email protected] >> <mailto:[email protected]>> a écrit : >> Well this was significantly smaller than I thought and also a simplication >> from the previous implementation. Well done for a bugfix! >> >> +1 >> >> /M >> >>> On 17 Dec 2014, at 17:45, Attila Szegedi <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Please review JDK-8067774 at >>> <http://cr.openjdk.java.net/~attila/8067774/webrev.00 >>> <http://cr.openjdk.java.net/~attila/8067774/webrev.00>> for >>> <https://bugs.openjdk.java.net/browse/JDK-8067774 >>> <https://bugs.openjdk.java.net/browse/JDK-8067774>> >>> >>> This fixes the issue reported with asciidoctor. The change is not trivial – >>> I had to introduce a change in the way LocalVariableTypeCalculator performs >>> its expression type calculations; it now uses a type stack. (If I want to >>> be honest, I should have realized this is the right way to implement it >>> from the beginning… Oh well, live and learn.) As a beneficial consequence, >>> a lot of code actually became simpler; the whole business with using a >>> Symbol->Type function to evaluate expression types is no longer necessary >>> (all changes in the various expression classes are to do with removal of >>> that logic). >>> >>> Thanks, >>> Attila. >> >
