Suppressing Highlights

ReSharper allows suppressing configurable highlights with specially formatted comments, such as:

// ReSharper disable once UnassignedReadonlyField
public static readonly double? UNDEFINED_OPACITY;

Similarly, highlights relating to compiler warnings are not shown if the warnings are disabled in project settings, or via a #pragma directive. Highlights are also not shown in generated files, or code regions that should be treated like generated code, as specified in the Generated Code options page.

note

Element Problem Analysers are run by existing daemon stages. For built in languages, ReSharper already handles filtering highlights. If you wish to host Element Problem Analysers for your own language, you will need to follow the advice here.

ReSharper will display all highlights that the daemon stage process returns for a specific file. It is up to the daemon stage process itself to perform the appropriate filtering, based on the file's language and requirements. The daemon stage can use the FilteringHighlightingConsumer class to perform the filtering as the results are collected during analysis.

The IDaemonStageProcess.Execute method expects a DaemonStageResult that contains a list of highlights to apply. To make it easier to capture this list, ReSharper provides a couple of implementations of the IHighlightingConsumer interface. This interface provides context, such as access to settings, as well as a method to consume a highlight. They also return the list of highlights to be used in DaemonStageResult. Typically, a daemon process will create one of these classes and pass it to the code doing the actual analysis, which will add highlights as it works.

The default implementation DefaultHighlightingConsumer is a simple class, and captures all highlights passed to it. This is useful for languages where filtering is not appropriate - perhaps the language doesn't support comments, or have compiler warnings.

The FilteringHighlightingConsumer class will check that the highlight should be shown before it's added to the list. The class will, in priority order:

• Filter out any highlights with a severity of Severity.DO_NOT_SHOW.

• Always include highlights with a severity of Severity.INFO.

• Filter out all other highlights for non-user files (such as decompiled files).

• Include highlights that correspond to compiler errors.

• Filter out all highlights in a generated file, or that are located in a generated region.

• Filter out compiler warnings that have been disabled via #pragma or equivalent.

• Filter highlights by specially formatted comments.

note

The FilteringHighlightingConsumer class will automatically filter out highlights in generated files or regions. This means a daemon stage process, or individual highlights do not need to worry if code being analysed is generated or not - the highlights are filtered out before they are applied to the editor.

A typical daemon stage process Execute method that wanted to take advantage of FilteringHighlightingConsumer would look like this:

public virtual void Execute(Action<DaemonStageResult> committer)
{
  var consumer = new FilteringHighlightingConsumer(this, this.SettingsStore, this.File);
  this.File.ProcessThisAndDescendants(new MyRecursiveElementProcessor(this, consumer));
}

This creates a new instance of FilteringHighlightingConsumer, passing in the daemon stage, the current settings store and the file that will be processed. The consumer is then used to collect highlights, in this case via the MyRecursiveElementProcessor class that is being called for all nodes in the syntax tree. This is all there is to it. Highlights are now appropriately filtered.

Any daemon stage process deriving from CSharpIncrementalDaemonStageProcessBase will automatically get this functionality.