[Dagger Hilt] dagger module with same full name overriden in component

Current Behavior

In an application with two dagger module with the same package and the same name (for example in two different gradle-modules). If those modules are installed in any component with @InstallIn one of them will be overriden by the other silently.

Expected Behavior

Dagger Hilt should fail and warn the user about the collision. The user should not have two modules with the same name but Dagger Hilt should not silently override the module.

Context (Environment)

Dagger Hilt 29.1-alpha

module 1

package com.example.twin

@Module
@InstallIn(SingletonComponent::class)
interface FooModule {
    @Binds
    fun bindRandomSuff(
        impl: RandomStuffImpl
    ): RandomStuff
}

module 2

package com.example.twin

@Module
@InstallIn(SingletonComponent::class)
interface FooModule {
    @Binds
    fun bindAnotherRandomSuff(
        impl: AnotherRandomStuffImpl
    ): AnotherRandomStuff
}

generated code

// ...
import com.example.twin.FooModule
// ...
@Component(
      modules = {
          ActivityRetainedCBuilderModule.class,
          ServiceCBuilderModule.class,
          ApplicationContextModule.class,
          FooModule.class,
      }
  )
  @Singleton
  public abstract static class SingletonC implements HiltWrapper_ActivityRetainedComponentManager_ActivityRetainedComponentBuilderEntryPoint,
// ....

[bcorso]

No problem!

(Btw, I should have also explained that the reason we need to check the set of seen modules in AggregatedDepsProcessor is not because we expect duplicate classes but because we may try to process the same class multiple times. This can happen because the processor supports multiple annotation types (e.g. @Module, @InstallIn, etc…) so it’s possible that we try to process the same class multiple times if it’s annotated with multiple supported annotations.

[bcorso]

That is the set of seen modules in the current build unit.

If both FooModule classes are in the same build unit you will get an error: duplicate class: ...FooModule when compiling (Note: this error is from javac not Dagger) so AggregatedDepsProcessor doesn’t even get a chance to run.

If both FooModule classes are in different build units (which I think is your case since you said they were in different Gradle modules: module1 and module2) then each Gradle module will only see its own FooModule class.

Finally, if anything depends on module1 and module2 and tries to resolve FooModule, it will get whichever FooModule showed up first in the class path and doesn’t even know there was more than one.