Nile makes #testProvidedMethodBindingsWithConflicts fail in 3.9

> Hi,
>
> if you take a fresh 3.9 and run the test
> TraitCompositionTest>>#testProvidedMethodBindingsWithConflicts, it
> passes. Then, if you load Nile (package Nile-All from
> http://www.squeaksource.com/Nile/), the test fail. However, Nile has
> neither extension nor override in any trait related class.
>
> the test is:
>
> "
> testProvidedMethodBindingsWithConflicts
>  | traitWithConflict methodDict |
>  traitWithConflict := self createTraitNamed: #TraitWithConflict
>                                                             uses:
> self t1 + self t4.
>  methodDict := traitWithConflict methodDict.
>  self assert: methodDict size = 6.
>  self assert: (methodDict keys includesAllOf: #(
>                   #m11
>                   #m12
>                   #m13
>                   #m21
>                   #m22
>                   #m42
>                 )).
>  self
>      assert: (methodDict at: #m11) decompileString = 'm11
>     self traitConflict'
> "
>
> The failing assert is the last one. After having loaded Nile, m11 now
> is "self requirement" instead of "self traitConflict".
>
>
> Can you explain me what happens please?
>
>
> --
> Damien Cassou
>
>

> Hi Damien,
>
>
> I think I have found the bug, and it is in the following method:
>
> TraitMethodDescription>>requiredMethodForArguments: aNumber
> ifAbsentPut: aBlock
>    "ConflictMethods is an array that caches the generated conflict
>    methods. At position 1: binary method; 2: unary method;
>    n+2: keywordmethod with n arguments."
>
>    ^(RequiredMethods at: aNumber)
>        ifNil: [ConflictMethods at: aNumber put: aBlock value]
>
>
> This results in the following easy to diagnose symptom:
>
>
> Print-it:
>
>
> ((TraitMethodDescription classPool at: #ConflictMethods) at: 2)
> decompileString
>
> gives:
>
> 'm11
>    self requirement'
>
> instead of:
>
> 'm11
>    self traitConflict'
>
>
> But I'm a bit rusty, so please double check me, and then send in the
> trivial fix. Ah, the wonders of caches/copy&paste...
>
> Daniel
>
>
> Damien Cassou wrote:
>
>> 2007/6/9, stephane ducasse <[hidden email]>:
>>> can you add that to mantis and add also the problems you describe in
>>> the paper (about self requirement) taking precedence on ...
>>
>> http://bugs.squeak.org/view.php?id=6533
>> http://bugs.squeak.org/view.php?id=6534
>>
>

> A couple of conclusions:
>
> 1. It wasn't Nile's fault. Somehow loading Nile changed the order of
> execution, exposing this tricky bug.
>
> 2. I seriously doubt that generating the required and conflict method
> templates is so expensive and common that it really requires a cache.
> Maybe that cache can be simply removed? it also seems to be one of the
> causes behind bug 6445.
>
> 3. There's a whole bunch of bugs open on the Traits tools: 1764, 6411,
> 3789, and implementation: 5526, 6445. Some of these are assigned to me,
> but I've been very inactive lately. Who's interested in giving Traits a
> little love?
>
> 4. I think that caches are a really evil necessity.  Maybe less
> theoretically interesting, but IMO far more practically interesting than
> the multiple inheritance problem. Anyone know of tool/language feature
> ideas to make them less evil?
>
>
> Daniel
>
> PS. The bug is that we update the ConflictMethods cache when we don't
> find what we need in the RequiredMethods cache, and with the wrong
> thing. The bug perversely doesn't affect the RequiredMethods semantics,
> while disabling completely any benefits of having a cache. Cute!
>
>
> Daniel Vainsencher wrote:
>
> > Hi Damien,
> >
> >
> > I think I have found the bug, and it is in the following method:
> >
> > TraitMethodDescription>>requiredMethodForArguments: aNumber
> > ifAbsentPut: aBlock
> >    "ConflictMethods is an array that caches the generated conflict
> >    methods. At position 1: binary method; 2: unary method;
> >    n+2: keywordmethod with n arguments."
> >
> >    ^(RequiredMethods at: aNumber)
> >        ifNil: [ConflictMethods at: aNumber put: aBlock value]
> >
> >
> > This results in the following easy to diagnose symptom:
> >
> >
> > Print-it:
> >
> >
> > ((TraitMethodDescription classPool at: #ConflictMethods) at: 2)
> > decompileString
> >
> > gives:
> >
> > 'm11
> >    self requirement'
> >
> > instead of:
> >
> > 'm11
> >    self traitConflict'
> >
> >
> > But I'm a bit rusty, so please double check me, and then send in the
> > trivial fix. Ah, the wonders of caches/copy&paste...
> >
> > Daniel
> >
> >
> > Damien Cassou wrote:
> >
> >> 2007/6/9, stephane ducasse <[hidden email]>:
> >>> can you add that to mantis and add also the problems you describe in
> >>> the paper (about self requirement) taking precedence on ...
> >>
> >> http://bugs.squeak.org/view.php?id=6533
> >> http://bugs.squeak.org/view.php?id=6534
> >>
> >
>
>
>