OK, the #bogus flags are gone :) Colin write the tests and I fixed the compiler. I've also fixed the literal duplication issue (which indeed is a side-effect of introducing Environments). But in doing so the Decompiler is broken for v := Binding := expr. Kudos to anyone who can fix this (I'm busy fixing a horrible bug of my own).<br>
<br><div class="gmail_quote">On Tue, Apr 2, 2013 at 7:46 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Mar 29, 2013 at 11:21:00AM -0400, David T. Lewis wrote:<br>
> On Fri, Mar 29, 2013 at 03:04:20PM +0000, Frank Shearar wrote:<br>
> > On 29 March 2013 14:17, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> > ><br>
> > > I moved these two new tests from Inbox to Trunk. One test fails on recent<br>
> > > trunk images. I do not know if this is a bug or a feature, but I cannot<br>
> > > explain the regression so I don't want to assume it's a feature.<br>
> > ><br>
> > > Dave<br>
> ><br>
> > <a href="http://build.squeak.org/job/SqueakTrunk/237/testReport/junit/Tests.Compiler/CompilerTest/testMaxLiteralsWithClassReferenceInClosure/" target="_blank">http://build.squeak.org/job/SqueakTrunk/237/testReport/junit/Tests.Compiler/CompilerTest/testMaxLiteralsWithClassReferenceInClosure/</a><br>
> ><br>
> > shows the test failure.<br>
><br>
> The actual change to the image that causes this test failure occurred between<br>
> SqueakTrunk/212 and SqueakTrunk/213. In other words, if this test had been<br>
> part of the test suite all along, then you would have seen the failure appear<br>
> in 213.<br>
><br>
> I suspect that this is a side effect of class lookups associated with the Environments<br>
> changes, but I cannot say if it is a bug or an explainable variation. Either way<br>
> it's good to note the change, and we can either fix the bug or fix the test<br>
> as needed.<br>
<br>
(self flag: #dubious and: [self flag: #bogus]) ifTrue: [self askForGuidance]<br>
<br>
LiteralVariableNode>>sizeCodeForStore: is flagged thus, which I suspect<br>
is somehow related to the apparently incorrect warning about too many literals.<br>
<br>
Reducing to a smaller test case, compiling 'Time now' yields a parse tree<br>
with LiteralVariableNode {Time} that has code -4 which causes dual reserving<br>
in sizeCodeForValue: and this in turn leads to a mis-counting of literals<br>
in the encoder.<br>
<br>
In an earlier version of trunk, the same LiteralVariableNode has a non-negative<br>
code value that does not produce the dual reserving in sizeCodeForValue:<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>