Yay! And CompilerTest>>testMaxLiteralsWithClassReferenceInClosure is green now :)
Don't get me wrong, I really appreciated those #bogus flags. Seriously. It was an excellent clue that I should stop random debugging and ask for help from someone who might actually know what they were doing ;-)
Dave
On Wed, Apr 03, 2013 at 03:34:59PM -0700, Eliot Miranda wrote:
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@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@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/...
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