[squeak-dev] Why is #String->String an Alias?

Frank Shearar frank.shearar at gmail.com
Tue Dec 17 22:54:36 UTC 2013


On 17 December 2013 22:27, Chris Muller <asqueaker at gmail.com> wrote:
> I wrote:
>
> On Sat, Dec 14, 2013 at 4:33 PM, Chris Muller <ma.chris.m at gmail.com> wrote:
>>
>> I'm trying to get a picture of our state of quality (for release) in
>> terms of our tests.
>>
>> Here are failing tests in Trunk (as debuggable expressions):
>> ... snip...
>>
>> 5.  (MethodHighlightingTests selector: #testMethodHighlighting) debug.
>
> Working on this one today.  The root cause of the test breakage seems
> to be the fact that the variable binding for String is now an Alias,
> which responds "true" to #isSpecialReadBinding.
>
> This causes LiteralVariableNode>>#sizeCodeForValue: to bypass the
> guard at the top of that method, calculating a different value than it
> otherwise would.
>
> What should be done?

(right arrow, enter)

Right. I'm not sure what should be done, but we've seen Aliases
causing trouble elsewhere. IIRC I chased a semi-wild goose finding out
that #String -> Alias -> ClassBinding pointing to String isn't the
same as a ClassBinding pointing to String.

Colin right asked why we have Aliases at all (because at the moment we
only have one Environment, hence no imports, hence no need for any
Aliases). We don't know where they came from. Attempting to Compiler
recompileAll doesn't get right of them.

frank


More information about the Squeak-dev mailing list