Improve error message when Dagger compiler not run over module

[arimu1]

Summary

When a @Module lives in a dependency that was compiled without the Dagger annotation processor / KSP plugin, generated component code references missing *Factory types and the user only sees a vague javac "does not exist" error.

This PR detects that situation during component validation and reports a clear diagnostic:

The Dagger factory type lib.LibraryModule_ProvideStringFactory is missing. This usually means the Dagger compiler was not applied to the module lib.LibraryModule where the binding is defined. Ensure that the dependency that contains that module runs the Dagger annotation processor (or KSP plugin).

Approach (aligned with option 1 from #5146, using the existing knownModules set so it works for both Javac and KSP):

• Modules processed in the current compilation are recorded via ModuleValidator.addKnownModules (as before).
• For transitive modules on a component that are not from the current compilation, require that each @Provides / @Produces factory exists on the classpath.
• Skip modules from the current compilation: their factories are generated in-round by ModuleProcessingStep and may not yet be visible via findTypeElement.
• @Binds-only modules do not require factories and are unaffected.

Fixes #5146

Test plan

• bazel test //javatests/dagger/internal/codegen:ModuleMissingFactoryErrorTest
• bazel test //javatests/dagger/internal/codegen:AssistedFactoryTest
• bazel test //javatests/dagger/internal/codegen:ModuleValidationTest
• No open prior PR for Better error message when Dagger compiler not run over module. #5146 (re-checked before open)

[bcorso]

Thanks! Overall, this LGTM.

[bcorso]

Why do you need to check both knownModules and knowModuleNames?

[arimu1]

@bcorso Thanks for the review.

knownModules is the historical Set<XTypeElement> filled by addKnownModules. I added knownModuleNames because in multi-round / multi-step processing the XTypeElement instance for the same module is not always identity-equal to the one stored in knownModules (different rounds can produce distinct element wrappers for the same qualified name). The name set makes “module from current compilation” stable across those wrappers.

If you prefer a single source of truth, I can drop the XTypeElement set for this check and only use qualified names (or the reverse if you know identity is reliable here). Happy to simplify either way.

[bcorso]

knownModules is the historical Set<XTypeElement> filled by addKnownModules. I added knownModuleNames because in multi-round / multi-step processing the XTypeElement instance for the same module is not always identity-equal to the one stored in knownModules (different rounds can produce distinct element wrappers for the same qualified name). The name set makes “module from current compilation” stable across those wrappers.

Thanks, yeah, I noticed this too while reviewing your change and started a fix to switch over to XTypeElement -> XClassName. Just wanted to make sure there wasn't some other reason you were checking both.

If you prefer a single source of truth, I can drop the XTypeElement set for this check and only use qualified names (or the reverse if you know identity is reliable here). Happy to simplify either way.

Yes, but you can leave it as is since I'll be submitting a separate change to fix the XTypeElement -> XClassName first.

Also, just a heads up, GitHub is not Dagger's source of truth so we can't submit this PR directly. I will need to copy it into Google's repo and then merge the changes into GitHub in a separate PR (though I will attribute the change to you so you get credit).