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 -
>> 
>> 
>> 
>> 
>> 
>> 
>