Inter-Method type guessing

[LeonMatthes]

Currently, the type guesser only analyses the method it is started on and a few methods used to access local variables.

Whenever it hits an unknown method, it stops.
Of course, this could be changed to simply start analysis if the return value of the found method.

Problems:

• Only unary methods could be analysed
• How to analyse a method with multiple returns?

[LinqLover]

However, it would be possible to analyse the code of the method with conventional means to try to find the returned type.

Do you mean something like this?

When evaluating ^ self foo saturation, given the following method, guess the return type of foo:

foo
    ^ Color random

Sounds ingenious & delightfully complex! 😀
At a first glance, I would suppose it could come down to an algorithm similar to the following one:

• scan each cyclomatic execution branch of the method
• search for:
  • literals
  • message sends, and recursively continue search on the invoked methods (when a cycle is detected, discard the current branch)
  • calls on class objects, here we could apply instance guessing (Proposal: Instance guessing #32)
  • if found a call to #basicNew on a class object, we know the return type
  • same goes for some other primitives (#shallowCopy, #primitiveChangeClassTo:)
  • for other literals, we could define a quite large dictionary of constants: arithmetic operations, SmalltalkImage>>#getSystemAttribute: and many others ...
  • respect implicit return (^self)
• finally, add all possible types into a Set
• cache the results per method, because this algorithm sounds quite heavy
  • maybe perform type guessing in a background thread (as Shout does), and/or start it whenever a method is compiled (as AutoTDD does)? (No premature optimization!)

Challenges:

• Parametrized methods: There are enough cases like #min: where the argument expression could be type-guessed and passed to the type-guesser of the parametrized method. This would lead to some meta-model of methods, parameters and MessageSends ...
• Special control flows: Why shouldn't it be possible to guess the type of, for example, [(1 to: 5) do: [:i | ^ i]] on: Error do: [^ nil]?

  • Guess the type of block-returns as an input for typeguessing of the receiver

  • Add further primitive support (for example, #on:do: might return an instance of self value class or handlerAction value class).

    Really complicated: Dealing with Exception>>#return: and others ...

• Don't mess up with the fact that String new returns a String, while Behavior>>#new invokes #basicNew in the Behavior class. A metamodel must support a parameter/placeholder for the concrete receiver class.
• Should you always perform further type-guessing on the current instance of global vars? For example, in my image DisplayScreen nextObject yields Form, but when I restart my VM, it will likely yield a different object of a different class. The same might go for less exotic calls on global objects whose state is not immutable.