#803 getType() should give return type for a method

[Hedley Proctor]

I'm not sure if this is a bug or a conscious design choice. Perhaps if I explain it someone can tell me.

If I am writing a PMD rule that is interested in the type of an argument passed into a method, I can call getType() on the ASTExpression that represents the argument. This works fine if the expression is just a variable. However, frequently an argument may actually be a call to a method. In this situation, I would like to still call getType() on the ASTExpression. To me it seems that this should be possible and that it should give the declared return type of the method. However, when I have tried doing this, it just seems to return null. I was testing it with some code like:

i.equals(s);
boolean check = d.equals(returnsFloat());

Where returnsFloat is just a private method declared as

public Float returnsFloat()
{
return Float.valueOf(0.75f);
}

For the line i.equals(s), when I get the ASTExpression that represents the s variable, getType() correctly returns the variable type. By contrast, for the line d.equals(returnsFloat()), when I call getType() on the ASTExpression that represents the call to the method, I just get null.

Is this a bug? Or is there a reason why this call returns null?

[Ryan Gustafson]

The ClassTypeResolver does not currently make an effort to assign types to PrimaryExpressions. This is the most complex scenario. While it might be possible to make it work when the PrimaryExpression represents a Method class in the same .java file being processed, it would be flakey in scenarios where the given name 'returnsFloat' in your case, could present various other constructs (e.g. it could be a static method import).

To make this fully work, PMD needs to combine both the symbol table and the type resolution code, and essentially implement name resolution as per the JLS. The current implementaiton in PMD is a best effort in the absence of .class files (i.e. only what can be seen/inferred in the current .java file), and makes sense given that context. However, you're hitting upon a limitation, it's not possible to be 100% accurate without reading .class files in the classpath.

In summary, this is a known issue, and it is on my radar. I'd like to get it in for PMD 5.0, but I don't know if I'll be able to do it. I'll keep this bug open as a reminder to make sure your particular scenario is added to the test cases when I finally do get around to it.

BTW, you're still welcome to submit a patch to get things working for the particular scenario you describe.