Trampolines not created for Python summarized methods

[khatchad]

Referring to self in a Python summarized function, as far as I can tell, doesn't quite work, because there is no way to refer to the implicit parameter when there's no trampoline for the function. AFAIK, trampolines aren't created for summarized methods, and that's the only way in the IR implicit parameters can be referenced.

In the XML summaries, e.g., in tensorflow.xml, it is my feeling that self actually refers to the function object and not the object for which the function is invoked.

[khatchad]

Maybe we need a new XML tag; something like create_trampoline=true. That tag could be attached to the class or the ctor?

[khatchad]

I wonder if this creates a trampoline:

ML/com.ibm.wala.cast.python.ml/data/tensorflow.xml

Lines 492 to 493 in ddba21e

	<new def="z" class="Ltensorflow/functions/constant" />
	<call class="Ltensorflow/functions/constant" name="do" descriptor="()LRoot;" type="virtual" arg0="z" arg1="1" def="y" />

[khatchad]

For real Python code, the WALA front-end (via PythonLoader.defineMethodType) creates a completely separate IClass for every function/method (e.g., Lissue127b/C/foo). It then adds the MethodReference for Lissue127b/C/foo.do() to the class's methodTypes. When PythonConstructorTargetSelector runs, it uses the declaring class of that reference (Lissue127b/C/foo) to generate a PythonInstanceMethodTrampoline.

However, if we look at issue127b.xml:

    <class name="issue127b/C" allocatable="true">
      <method name="foo" descriptor="()LRoot;" numArgs="2" paramNames="self x">
        <return value="x" />
      </method>
    </class>

We are not modeling XML methods as function classes. We are defining them as standard Java-like methods directly on the issue127b/C class.

Because the standard PythonInstanceMethodTrampoline logic expects a function class to wrap (it literally calls cha.lookupClass(functionType)), it fails when used with XML methods because foo has no class; its declaring class is just Lissue127b/C. If we pass that to the trampoline generator, it tries to create a trampoline for the class C, not the method foo.

To fix this cleanly without touching core analysis logic, we can extend the Summary Reader / Engine (e.g., PythonAnalysisEngine.addSummaryBypassLogic). When it reads an XML method (that isn't do or import), it can automatically generate a synthetic function class for it on the fly, and then inject the standard trampoline allocations into the class's constructor, mirroring what PythonConstructorTargetSelector does for real code.