Controlling Highlighting

The results of analyzing code by several mechanisms provided by the IntelliJ Platform (Syntax errors, Annotators, Inspections) are converted to highlighting information used to highlight the code in the editor. However, in some contexts, the provided highlighting information is invalid or unnecessary.

Consider a tool that allows changing Java language's syntax by implicitly generating getters and setters for annotated fields during the build so that they can be omitted in class implementation:

class Person {
    @GetterSetter
    private int age;
}

// usage:
person.setAge(47); // valid at runtime

Java support in IntelliJ IDEA would report the above setter usage as an unresolved code symbol. The resulting error annotation would be valid from the Java language point of view but invalid in a project using such a tool.

Another case where highlighting code issues is unnecessary is old file revisions from VCS. For example, the old version of a file could be created in a different project context, with other libraries configured. If the old file version used the library that is not used by the project currently, it would cause reporting false-positive code issues.

The IntelliJ Platform exposes the extension point allowing a plugin to decide which highlighting information will be visible in the editor. To do that, a plugin has to provide an implementation of HighlightInfoFilter and register it in the com.intellij.daemon.highlightInfoFilter extension point. It contains a single method accept(), which should return true if a given HighlightInfo should be visible in the editor and false to ignore it.

Examples:

DebuggerHighlightFilter disabling reporting unhandled exceptions in the debugger code editor
LombokHighlightErrorFilter disabling false-positive error reports in a project using Lombok