I will be supporting a feature, but I need to suppress an inspection (ProblemDescriptor) generated by another plugin. How can I do this for a specific issue without suppressing all ProblemDescriptor?
It is com.intellij.codeInspection.InspectionSuppressor
/**
* Allows programmatic suppression of specific inspections.
* <p>
* Register via {@code com.intellij.lang.inspectionSuppressor} extension point.
*/
public interface InspectionSuppressor extends PossiblyDumbAware {
I have access to HighlightInfo, would it be possible to suppress/resolve/mute the Problem Description through HighlightInfo?
InspectionSuppressor requires you match the place manually in the suppressor for the given toolId.
It works before inspections run and the corresponding tool will not receive such elements.
Hi @yuriy.artamonov, thanks for your attention.
I tried with InspectionSuppressor, but it suppresses all tooid. 
The problem is that the toolId (SpringBootApplicationYaml of the Spring boot bundled plugin) does several other inspections and I don’t need to suppress all of them. In this case, the psiElement can have several ProblemDescriptors.
What I need is to resolve a specific one and not all the psiElement problems that are generated by the toolId. I would need some way to solve this problem programmatically. From the HighlightInfo, I have the details to filter, now I just need a way to silence/remove/suppress the problem so that it doesn’t generate the warning to the user.
I tried this way, but I was left with the question: “how to silence/remove/suppress the problem?”
plugin.xml:
<lang.inspectionSuppressor language="yaml" implementationClass="dev.eltonsandre.spring.boot.suppressor.SpringBootConfigurationInspectionSuppressor"/>
public class MsgBusConnectionSubscribe implements ProjectActivity {
Processor<HighlightInfo> processor = new CommonProcessors.CollectProcessor<>() {
public boolean process(HighlightInfo t) {
ProgressManager.checkCanceled();
return true;
}
};
@Nullable
@Override
public Object execute(@NotNull final Project project, @NotNull final Continuation<? super Unit> continuation) {
var msgBusConnection = project.getMessageBus().connect();
msgBusConnection.subscribe(DaemonCodeAnalyzer.DAEMON_EVENT_TOPIC, new DaemonCodeAnalyzer.DaemonListener() {
@Override
public void daemonFinished(@NotNull Collection<? extends FileEditor> fileEditors) {
for (FileEditor fileEditor : fileEditors) {
if (fileEditor instanceof PsiAwareTextEditorImpl psiAwareTextEditor) {
var file = psiAwareTextEditor.getFile();
PsiFile psiFile = VirtualFileUtil.findPsiFile(file, project);
if (psiFile == null) continue;
if (DaemonCodeAnalyzerEx.getInstanceEx(project).isErrorAnalyzingFinished(psiFile)) {
Editor editor = psiAwareTextEditor.getEditor();
DaemonCodeAnalyzerEx.processHighlights(
editor.getDocument(),
project,
HighlightSeverity.WEAK_WARNING,
psiFile.getTextRange().getStartOffset(),
psiFile.getTextRange().getEndOffset(),
processor
);
}
}
}
}
});
return null;
}
}
You will need to check both toolId and PsiElement. That is what we usually do in our suppressors
would it at least be possible to locate the ProblemDescription for each PsiElement?
I think is barely possible ( it is computed before inspection
Could you please tell us about the use case? Can we fix those on our side instead?
sure, my case is…
There are some Spring Boot and Cloud configurations that do not have metadata, and I am supporting these configurations. For the Spring Boot plugin (bundle), these configurations are indeed unknown and generate warnings and QuickFixes to create them. My plugin is focused on IntelliJ Community and brings some of these functionalities, which when installed in IntelliJ Ultimate, become redundant, which is bad for the user. In the UI, these inspections are disabled so that there is no redundancy of warnings and QuickFixes.
With the addition of support for these configurations, I need that at least those configurations that are unknown to Spring Boot Bundled, but known to my plugin, are marked as resolved and do not generate a warning for the user.
My attempts with InspectionSuppressor ended up disabling SpringBootApplicationYaml completely if psiElement has other inspections.
An example of support:
spring:
cloud.stream:
kafka:
default:
producer.configuration:
key: value
Cannot resolve configuration property ‘spring.cloud.stream.kafka.default’
I need to suppress only this issue and not affect the others.
I think you have PsiElement in suppressor, take a look at full path in YAML key and decide to suppress? Looks rather straightforward
org.jetbrains.yaml.YAMLUtil#getConfigFullName probably
This also looks like a false-positive on our side, let me confirm and we will fix it then. We must support Spring Cloud keys if they work at run time
This configuration is just an example. There are several others that also have no metadata. I have been tracking them down through the documentation and source code, manually adding the metadata so that I can generate autocomplete and inspections.
The fix for this specific configuration does not solve my use case.
The ConfigFullName check is not an issue. The problem is that the psiElement for the toolId has other inspections, which can only be known from the information contained in an object like HighlightInfo.
For example, within this inspection, there are also cases like:
- Missing map key
- Duplicate configuration key ‘key’
- Cannot resolve symbol ‘key’
- Missing index value
- … and others
And if you suppress by key plus toolId, you would risk suppressing all other inspections, AND the intention is only for the key
Cannot resolve configuration property ‘key’
Right, that is why we would prefer to fix the root cause on our side to not provide bad product
Issue on our side https://youtrack.jetbrains.com/issue/IDEA-369812