Code analysis across different classes custom rule

Hello,

  • Community EditionVersion 9.9.2 (build 77730)

I have a question regarding the code analysis from multiple files, classes.

In the concrete example below is it possible to check the format of the String pathFromB that is passed in the C.getData(pathFromB) method call.

So to be more concrete, I want to perform a check if a string from one class (class A) with a certain format is used as an argument for a specific method in a different class (in this case getData from class B).

Case:
Is it possible to register a violation. Ex. when analyzing class B a rule violation is thrown because getData cannot use paths with an .xml extension.

Input test file:

class A {
    String UNIX_PATH = "proj/dir/resources/file.xml";
    String xml = B.someMethodFromB(UNIX_PATH);
}

class B {
    public static String someMethodFromB(String pathFromB){
           return C.getData(pathFromB);
    }
}

class C {
    public static String getData(String pathFromC) {
        return pathFromC;
    }
}

Thanks in advance,

Toni

Hello contributors,

I am quite new to Sonar so maybe I didn’t provide enough context for the readers.

The problem I am facing is cross-file analysis from the same project:

ClassA → ClassB field → ClassB —> ClassC field → ClassC etc.

I want to exclude throwing a certain rule violation if a specific method is using a path with a certain extension, in my case .xml, if getData uses the path do not report a violation. The problem is if the method is maybe located in a different class than the one where the path with the extension is declared.

So cross-file checking would be required to inspect if the specific method is invoked with the path. From my current research and understanding this could be done via semantic analysis, so if someone has any suggestion on the topic of this kind of analysis or examples it would be greatly appreciated.

My other concern is if this is possible via the mentioned approach - the cost of running this kind of analysis in a larger codebase - the specific method could be called deeper in the analysis and not so quick as in the provided example above.

Thanks in advance,

Toni

Hi all,

Did I maybe put this post in the wrong forum topic and is some additional context needed?

Regards,

Toni

Hi Toni,

This is flagged for the language experts. Hopefully they’ll be along soon.

 
Ann

Hi Ann,

Thank you for the reply!

Best regards,

Toni

hey @tomato66,

The Java analyzer does not natively support cross-file analysis. However, in your specific case, I think you might be able to do without cross-file analysis.

If you are looking at reporting on the invocation of a specific method and with some value as an argument, and provided you are using this Java custom rule template , you can take the following approach:

  1. Visit method invocations until you find the one that matches your target (or use MethodMatchers)
  2. Try to resolve the value of the argument you want to verify (using asConstant(String.class))
  3. Report an issue if the argument violates the rule

I invite to look at existing examples throughout the code base to try and make use of these APIs but there are a couple of caveats you might need to consider.

  1. asConstant resolves simple expression such as constants and references to constants. If the argument is a concatenation or the result of a method call, you might miss something
  2. Constant resolution across files in unit tests is sometimes tricky and I would encourage to you test extensively manually that your rule implementation is working as expected.

Let us know if you need any clarification.

Cheers,

Dorian

1 Like

Hi Dorian @Dorian_Burihabwa,

Thank you for the extensive explanation, I am also interested if the violation can be thrown at the point where the constant has been declared? So basically, throwing the report issue at the constant declaration, if it is used by some method in this case?

I guess the check could be done, if there is a possibility to add the codebase I am using as a dependency to the check itself so we can inspect some classes from the used codebase?

If not, the solution of throwing the report issue at the constant declaration spot could I guess possibly be done recursively?

Best regards,

Toni

Hi @tomato66,
Unfortunately, the current reporting API does not support reporting on locations outside of the file where you are analyzing.

2 Likes

Thank you for your help @Dorian_Burihabwa and @ganncamp !

Regards,

Toni

1 Like