When the analysis succeeds, it doesn’t mean that the analyzer was able to understand all the analyzed code. If the analyzer fails on some parts of
your code, it will ignore them during the analysis. This rule will help you track these analysis failures.
There are many reasons why analysis failures can happen, here are the common ones:
- The code contains compile-time error(s).
-
flutter pub get, dart pub get, or similar commands were not executed.
- The types weren’t resolved correctly (some dependencies are missing or files weren’t generated).
- Use of new language features that are not yet supported by our analyzer.
How do they impact analysis? We cannot judge without looking at specific examples, as they contain a broad range of types of errors.
There are three recommended ways to deal with analysis failures:
- Fix compiler errors.
- Make sure you got all project dependencies, via
flutter pub get, dart pub get, …
- Make sure all referenced generated files were generated before the analysis.
If you cannot fix them, let us know through the Sonar Community forum.
Noncompliant code example
void fun(int x) {
print(x) // Noncompliant, missing ';'
}
Compliant solution
void fun(int x) {
print(x);
}
Noncompliant code example
Another example could be with missing generated classes
import 'package:generated/my_classes.dart'; // Noncompliant, Target of URI doesn't exist: 'package:generated/my_classes.dart'.
void main() {
print(MyClass().name); // MyClass type is missing
}
To fix this, make sure code generation task was executed before the analysis.
