Hi,

I committed the change Compiler-JorgeRessia.141

Basically the problem was that the interactive mode was not taken into
account in the Encode and BytecodeEncoder >> bindTemp: method.

bindTemp: name
        "Declare a temporary; error not if a field or class variable or
out-of-scope temp.
         Read the comment in Encoder>>bindBlockArg:within: and subclass
implementations."
        self supportsClosureOpcodes ifFalse:
                [^super bindTemp: name].
        scopeTable at: name ifPresent:
                [:node|
                "When non-interactive raise the error only if it is a duplicate"
                (node isTemp or: [requestor interactive])
                        ifTrue:[^self notify:'Name is already defined']
                        ifFalse:[self warnAboutShadowed: name]].
        ^self reallyBind: name

We tested it with Lukas and is working fine. However, we should see
that there are no further side effects.

Cheers,

Jorge


On Wed, Mar 3, 2010 at 9:37 AM, Stéphane Ducasse
<[email protected]> wrote:
> lukas can youreread because I tried to improve thte explanation.
>
>
>> In 1.1 and I think that this is the wrong version of the changes that was 
>> introduced
>> because the interface sucks
>> =================
>> Parser warningAllowed: true
>>
>> Object subclass: #Zork
>>       instanceVariableNames: 't'
>>
>> zork
>>
>>       | t |
>>       t := 1.
>>
>> I get "t appears to beunused in this method.Ok to remove it?"
>>
>> Now with
>>       Parser warningAllowed: false
>>
>> Object subclass: #Zork
>>       instanceVariableNames: 't'
>>
>> zork
>>
>>       | t |
>>       t := 1.
>>  the variable t shadows the instance variable without noticed
>>
>> So for Pharo we get simply for now issue Parser warningAllowed: true
>> to get it to the "normal" behavior.
>>
>> In 1.0
>> =================
>> The interface changes -> Parser warnUser
>> but we have the same silly broken pop up.
>>
>> Now I checked and in 3.9
>> =================
>>
>> we got  'Name is already defined.' which is the correct behavior
>> so it seems that this is not the warning preference that  are responsible of 
>> the problem.
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to