Custom ICompilerComponent runs fine in Gradle but IntelliJ editor shows errors

[dpkass]

I have a custom annotation processor implemented as a Manifold ICompilerComponent that injects helper methods into classes with annotated fields (@Localized).

Setup

• Processor type: manifold.api.type.ICompilerComponent
• Registration: META-INF/services/manifold.api.type.ICompilerComponent with FQCN of my component.
• Gradle:

// build.gradle
dependencies {
  testAnnotationProcessor "systems.manifold:manifold:2025.1.26"
  testAnnotationProcessor "com.tadafur.gov360:annotation-processors:0.0.1-SNAPSHOT"
  testCompileOnly "systems.manifold:manifold:2025.1.26"
  testCompileOnly "com.tadafur.gov360:annotation-processors:0.0.1-SNAPSHOT"
}

// settings.gradle
includeBuild "../annotation-processor"

IDE: IntelliJ IDEA 2025.1
Runtime version: 21.0.6+9-b895.109 aarch64 (JCEF 122.1.9)

• Manifold IntelliJ plugin installed and enabled
• -Xplugin:Manifold in Java Compiler → Additional command line parameters (module-specific for test)
• Annotation processing enabled (automatically by Gradle) in Settings → Build, Execution, Deployment → Compiler → Annotation Processors
• Processor path contains both manifold-*.jar and my annotation-processors-0.0.1-SNAPSHOT.jar

Full path: /Users/Mac/.gradle/caches/modules-2/files-2.1/systems.manifold/manifold/2025.1.26/b7174e8ff4d4c5b39b2bed817e47ba9cf2372551/manifold-2025.1.26.jar:/Users/Mac/Projects/[sensitive]/libs/annotation-processors/build/libs/annotation-processors-0.0.1-SNAPSHOT.jar:/Users/Mac/.gradle/caches/modules-2/files-2.1/systems.manifold/manifold-rt/2025.1.26/d57b7c7d4582913bb2d6781a53e6f16bded77b9b/manifold-rt-2025.1.26.jar:/Users/Mac/.gradle/caches/modules-2/files-2.1/systems.manifold/manifold-util/2025.1.26/12ef4c31eb68695295bbbd693b1e644294ce8460/manifold-util-2025.1.26.jar

Expected

IntelliJ PSI picks up my annotation processor, and recognizes the methods.

Actual

When editing code, methods injected by my component (e.g., setLocalizedName(Locale, String)) are flagged as unresolved with red text.
However:

• Running gradle test compiles and executes successfully
• IntelliJ’s Build → Rebuild Project also succeeds (my component logs appear in build output)
• The generated methods work correctly at runtime

So the problem is editor resolution only — PSI seems unaware of injected members even though the plugin and compiler component run fine during builds.

What I’ve tried

• Added both Manifold and my component JAR to test compile classpath (testCompileOnly)
• Invalidate caches & restart

Question:
Does the IntelliJ Manifold plugin fully support custom ICompilerComponents in the editor PSI model? If so, is there additional configuration needed to make the editor aware of injected members?

[rsmckinney]

Does the IntelliJ Manifold plugin fully support custom ICompilerComponents in the editor PSI model?

TLDR: No, not without explicit plugin support.

The IntelliJ Manifold plugin directly supports specific features like type manifolds, extension methods, properties, and optional parameters because their IDE behavior is well-defined. In contrast, ICompilerComponent is a general-purpose API for hooking into compiler activity. The IDE can’t infer the language surface or PSI changes for arbitrary ICompilerComponent implementations, so support has to be added case-by-case, either via a separate plugin or as a contribution to the Manifold plugin.

For example, the Manifold properties feature is implemented using ICompilerComponent. It defines annotations that:

• Trigger parser and class layout changes
• Generate property-related methods at different compiler stages (some before type attribution, some only at class writing)

This is to illustrate that a generic ICompilerComponent can’t be automatically understood by the IDE.

For your @Localized use case, if you’re generating sibling methods, you might get better results using IExtensionClassProducer to create extension methods. The IntelliJ plugin already fully supports these, so your feature would work in the IDE without extra plugin code. See this manual extension class generation example.

[dpkass]

Thank you very much for the thorough explanation. I looked a bit into the IExtensionClassProducer, specifically into the sample with .favs classes. If I'm not mistaken, the idea is that the underlying classes are extended based on different file types.

In my case I just generate delegation methods with a postfix that I want to alleviate future devs of. E.g. getLocalizedName for an Entity with a name that has different translations. The type is usually just a Wrapper around a Map<Locale, T> with some extra functionality. My question is, would the IExtensionClassProducer still be correct for that use-case, i.e. class extension based on annotations, rather than other files, like .favs format?

[rsmckinney]

Ah, I see. Sorry for the mixup, IExtensionClassProducer is unsuitable for your use-case.

Your current approach is best, unfortunately that means the IJ plugin needs to support it explicitly.

But your use-case is a common, but unmet need with annotation processors — it’s pretty much a specialized annotation processor that modifies user source code by adding new members. This pattern is a good candidate as a new type of extension, similar to manifold’s extension classes, but acting on user source.

This is all to say I like this idea and the IJ plugin can support it directly.

Unfortunately, implementing this will take time, and wouldn’t be on the schedule for another ~8 weeks.

[dpkass]

I would have loved to contribute, but frankly I'm in a squeeze between Uni and work. Though, if you need anyone to try it out, when you're done, I'm happy to.