CompiledMethodTest >> #testMethodClass

This fails because the CompiledMethod from a removed class returns nil
for its #methodClass.

The test implies that an orphaned method will still know its removed class.

However, Environment >> #forgetClass:logged: clearly nils out the
binding of a removed class:

    "snip other stuff"
    undeclared declare: aClass name from: declarations.
    declarations removeKey: aClass name ifAbsent: [].
    [undeclared at: aClass name put: nil]
        on: AttemptToWriteReadOnlyGlobal
        do: [:n | n resume: true].
    self binding: binding removedFrom: self]

So is this just an API change? Should the test be updated, or is this a bug?

On 10 January 2014 20:41, Colin Putney <[hidden email]> wrote:
>
>
>
> On Fri, Jan 10, 2014 at 4:56 AM, Frank Shearar <[hidden email]>
> wrote:
>>
>> This fails because the CompiledMethod from a removed class returns nil
>> for its #methodClass.
>>
>> The test implies that an orphaned method will still know its removed
>> class.
>>
>> However, Environment >> #forgetClass:logged: clearly nils out the
>> binding of a removed class:
>>
>>     "snip other stuff"
>>     undeclared declare: aClass name from: declarations.
>>     declarations removeKey: aClass name ifAbsent: [].
>>     [undeclared at: aClass name put: nil]
>>         on: AttemptToWriteReadOnlyGlobal
>>         do: [:n | n resume: true].
>>     self binding: binding removedFrom: self]
>>
>> So is this just an API change? Should the test be updated, or is this a
>> bug?
>
>
> It's not an API change, because SystemDictionary>>forgetClass:logged: does
> the same thing. But I don't know if the test is right.

In which case the test was passing by accident, until relatively
recently: this used to pass, back in the day.

frank