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).

On Tue, Apr 2, 2013 at 7:46 PM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Fri, Mar 29, 2013 at 11:21:00AM -0400, David T. Lewis wrote:
> > On Fri, Mar 29, 2013 at 03:04:20PM +0000, Frank Shearar wrote:
> > > On 29 March 2013 14:17, David T. Lewis <lewis at mail.msen.com> wrote:
> > > >
> > > > I moved these two new tests from Inbox to Trunk. One test fails on
> recent
> > > > trunk images. I do not know if this is a bug or a feature, but I
> cannot
> > > > explain the regression so I don't want to assume it's a feature.
> > > >
> > > > Dave
> > >
> > >
> http://build.squeak.org/job/SqueakTrunk/237/testReport/junit/Tests.Compiler/CompilerTest/testMaxLiteralsWithClassReferenceInClosure/
> > >
> > > shows the test failure.
> >
> > The actual change to the image that causes this test failure occurred
> between
> > SqueakTrunk/212 and SqueakTrunk/213. In other words, if this test had
> been
> > part of the test suite all along, then you would have seen the failure
> appear
> > in 213.
> >
> > I suspect that this is a side effect of class lookups associated with
> the Environments
> > changes, but I cannot say if it is a bug or an explainable variation.
> Either way
> > it's good to note the change, and we can either fix the bug or fix the
> test
> > as needed.
>
> (self flag: #dubious and: [self flag: #bogus]) ifTrue: [self
> askForGuidance]
>
> LiteralVariableNode>>sizeCodeForStore: is flagged thus, which I suspect
> is somehow related to the apparently incorrect warning about too many
> literals.
>
> Reducing to a smaller test case,  compiling 'Time now' yields a parse tree
> with LiteralVariableNode {Time} that has code -4 which causes dual
> reserving
> in sizeCodeForValue: and this in turn leads to a mis-counting of literals
> in the encoder.
>
> In an earlier version of trunk, the same LiteralVariableNode has a
> non-negative
> code value that does not produce the dual reserving in sizeCodeForValue:
>
> Dave
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130403/00404e93/attachment.htm