Inspection stops because "file is too complex"; how do I change that?

Answered

I was interested to learn how well the static analysis is handled by CLion, so I converted a 25 year old monstrous 'C' project of mine to use CMake build rules and actually managed to build it.

Data flow analysis, however, stops with an error of "File is too complex to perform data-flow analysis" under "Context-sensitive analysis". I can understand that: the project consists of several files which each contain more than 1600 lines of code, broken down into functions of 300-600 lines each.

This may be as bad as it gets. However, it would be nice to know that CLion could be used to refactor such a monster. I would like to see the code inspection's analysis before considering rewriting the code, not the other way round.

9 comments
Comment actions Permalink

Unfortunately currently it is not possible to override DFA limits.

0
Comment actions Permalink

The static analysis does work in part for files of the size and scope I mentioned, but the data flow analysis takes a very long time to get to the point where it gives up.

This is not a big issue, but it would have been interesting to see the whole process work out; ugly, overly complex code abounds, and CLion is also a tool intended to make refactoring easier, which is why I expected that the analysis operation would be less constrained.

Here's hoping that once the product leaves the EAP stage, the restrictions that govern data flow analysis may be tunable or at least not quite as limiting.

Should I file an enhancement request?

Thank you for responding :-)

0
Avatar
Alexander Kirillin
Comment actions Permalink

Olaf, what kind of analysis do you want to run? CLion has many inspections that can be called "static analysis". "Context-sensitive DFA" is the most complex analysis in CLion, you can read about it here: http://blog.jetbrains.com/objc/2014/06/context-sensitive-analysis-with-appcode-3-never-miss-a-value-again/. There's no way to accelerate it unless you decrease the size of the source files.
However, there are other DFA analyses, which work for files of any size, e.g.: non-initialized variables, non-used values, unreachable/dead code analysis, escape analysis, etc.

1
Comment actions Permalink

I was hoping that the process which eventually gives up and prints an error message with regard to the complexity of the file would give me insights I did not already have. At 1600 lines, with only three functions in that file, it has "refactor me!" written all over it ;-)

From what the error message says I cannot tell what type of data flow analysis is being omitted. I did not see any hints to the effect of variables being used before they are initialized, or not used at all, which makes me suspicious considering how old this specific code is (more than 25 years).

As I wrote before, the full static analysis not working for this "pathological type" of project is not a big deal for me. I understand that the line has to be drawn somewhere. This appears to be the type of code which needs manual cleanup before it can be expected to be analyzed by CLion.

0
Avatar
Alexander Kirillin
Comment actions Permalink

Olaf, please help me to understand you. Do you mean that CLion incorrectly shows some warnings? According to your answer, it's "variable might not have been initialized". Could you share some example when it's not working?

0
Comment actions Permalink

I'm sorry, I was not being clear.

The code inspection stops with an error of the file being too complex for data flow analysis, and this is the only message I see for this specific file.

This could mean that there are no issues with unitialized/unused variables in the code, or it could mean that the inspection process was aborted before any such insights could have been gained.

For an end-user it's difficult to tell if the output may be a "false negative" or a "true negative" test result.

0
Avatar
Alexander Kirillin
Comment actions Permalink

"Context-snsitive data flow analysis" inspection and "variable might not have initialized" inspection are two different inspections. If the first one failed to run because of timeout, this won't affect the second one. In fact, the second inspection always completes.

0
Comment actions Permalink

Is it still impossible to change this behavior? From my side will be the best solution when you add a checkbox with "Turn off limitation (possible problems with RAM consumption/CPU using/whatever else)".

I use CLion and a lot of my files (LLVM project, Nlohmann JSON, whatever huge else) isn't inspected, because "File is too complex". It's nervous.

1
Comment actions Permalink

@Alexander, it is still impossible to override DFA limits. We have some related issues in our tracker, for example, https://youtrack.jetbrains.com/issue/CPP-12138. Feel free to comment or upvote, or create a new one.

0

Please sign in to leave a comment.