I went through all those senders in my Trunk image and found that they 
won't be affected by the change of evaluation order.

Levente

On Sat, 22 Apr 2017, Levente Uzonyi wrote:

> Actually it's possible to have one variable and one non-literal non-variable 
> node where the latter changes the value of the former, so the condition 
> should be:
>
> 			(node isMessage
> 				and: [ (#(to:do: to:by:do:) includes: node 
> selector key)
> 				and: [ node receiver isLiteralNode not
> 				and: [ node arguments first isLiteralNode not
> 				and: [ node receiver isVariableNode not
> 					or: [ node arguments first 
> isVariableNode not ] ] ] ] ])
>
> Levente
>
> On Sat, 22 Apr 2017, Levente Uzonyi wrote:
>
>> This seems to work:
>> 
>> methods := (SystemNavigation default allCallsOn: #to:do:) asSet.
>> methods addAll: (SystemNavigation default allCallsOn: #to:by:do:).
>> methods := CurrentReadOnlySourceFiles cacheDuring: [
>> 	methods select: [ :methodReference |
>> 		| ast found |
>> 		ast := methodReference actualClass newParser parse: 
>> methodReference sourceCode class: methodReference actualClass.
>> 		found := nil.
>> 		ast accept: (ParseNodeEnumerator ofBlock: [ :node |
>> 			(node isMessage
>> 				and: [ (#(to:do: to:by:do:) includes: node 
>> selector key)
>> 				and: [ node receiver isLiteralNode not
>> 				and: [ node receiver isVariableNode not
>> 				and: [ node arguments first isLiteralNode not
>> 				and: [ node arguments first isVariableNode 
>> not ] ] ] ] ])
>> 				ifTrue: [ found := node ] ]).
>> 		found notNil ] ].
>> SystemNavigation default
>> 	browseMessageList: methods sorted
>> 	name: 'complex senders of to:do:'
>> 	autoSelect: 'to:'.
>> 
>> Levente
>> 
>> On Sat, 22 Apr 2017, Nicolas Cellier wrote:
>> 
>>> 
>>> 
>>> 2017-04-21 23:05 GMT+02:00 Nicolas Cellier 
>>> <nicolas.cellier.aka.nice at gmail.com>:
>>>       I see more than 1000 senders but most of them are in the style 1 to: 
>>> ...
>>> If any of receiver or 1st arg is a LiteralNode, no need to analyze, so it 
>>> should be possible to write a small analyzer to select non trivial cases 
>>> and review manually. Something like:
>>> 
>>> SystemNavigation default
>>>     browseMessageList: ((SystemNavigation default allCallsOn: #to:do:) 
>>> select: [:e |
>>>         | ast found |
>>>         ast := e actualClass newParser parse: e sourceCode class: e 
>>> actualClass.
>>>         found := nil.
>>>         ast accept: (ParseNodeEnumerator
>>>             ofBlock: [:node | ((node isKindOf: MessageNode)
>>>                     and: [node selector key = #to:do:
>>>                     and: [node receiver isLiteralNode not
>>>                     and: [node arguments first isLiteralNode not]]])
>>>                 ifTrue: [found := node]]).
>>>         found notNil])
>>>     name: 'complex senders of to:do:'
>>>     autoSelect: true.
>>> 
>>> Above script did not find any complex senders though I see some, so I must 
>>> have screwed something, but you get the idea.
>>> 
>>> Then there is the case of to:by:do: to analyze too.
>>> 
>>> 
>>> Ah, my script failed because to:do: is transformed at this stage 
>>> (disguised in #to:by:do:)...
>>> 
>>> SystemNavigation default
>>>     browseMessageList: ((SystemNavigation default allCallsOn: #to:do:) 
>>> select: [:e |
>>>         | ast found |
>>>         ast := e actualClass newParser parse: e sourceCode class: e 
>>> actualClass.
>>>         found := nil.
>>>         ast accept: (ParseNodeEnumerator
>>>             ofBlock: [:node | ((node isKindOf: MessageNode)
>>>                     and: [(node selector key = #to:do: or: [node selector 
>>> key = #to:by:do: ])
>>>                     and: [node receiver isLiteralNode not
>>>                     and: [node arguments first isLiteralNode not]]])
>>>                 ifTrue: [found := node]]).
>>>         found notNil])
>>>     name: 'complex senders of to:do:'
>>>     autoSelect: #to:do:
>>>  
>>> But I can't test other trivial cases when node arguments first 
>>> isVariableNode, because it allways is after transform.
>>> It would be necessary to disable transform during analysis...
>>> 
>>> 
>>> 2017-04-21 16:08 GMT+02:00 Bert Freudenberg <bert at freudenbergs.de>:
>>>       On Fri, Apr 21, 2017 at 1:56 AM, Eliot Miranda 
>>> <eliot.miranda at gmail.com> wrote:
>>>             On the order of evaluation bug, does anyone have any memory of 
>>> which methods depended on this bug?
>>> 
>>> 
>>> No idea ...
>>> 
>>> - Bert -
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>