Raffi Khatchadourian
Raffi Khatchadourian
I think this is happening because we are (interprocedurally) processing two different types of SSA instructions, those corresponding to for each statements and field reads: ``` [FINE] Processing instruction: 274...
Can you change the comment for test 2 to refer to this new issue instead of #24?
Since the super class `__call__()` calls the subclass' `__call__()`, this is most likely blocked on #107.
There's another case as well. The one in the description describes a scenario where the function has parameters. But, the decorator also could have parameters, and there's a different problem...
Does https://github.com/wala/ML/blob/16acfbcf22c66a220176c1b95d30e7026c7231b2/com.ibm.wala.cast.python/source/com/ibm/wala/cast/python/util/Util.java#L20-L33 help? I added Pytest entry points using this code (though it doesn't consider the decorators). I didn't override the default entrypoints; I kept those intact. Do you not...
Note that the test case file `classes3.py` seems to include a class with a user-defined super class.
`DistributedValues` seems to be an iterable construct.
We could treat these as a dataset.
Seems to work when using Jython 3.
My guess is that `TypeInference.make()` should be returning a different type. I see that there is `com.ibm.wala.cast.java.analysis.typeInference.AstJavaTypeInference` in WALA but no `com.ibm.wala.cast.python.analysis.typeInference.AstPythonTypeInference` in wala/ML.