Anvil with trackSourceFiles enabled double binds on scope change

[Laimiux]

What

If there are subcomponents in your graph as such

@MergeComponent(AppScope::class)
interface AppScope {
  fun mySubcomponent(): MySubcomponent
}

@MergeSubcomponent(SubcomponentScope::class)
interface MySubcomponent

Moving a dependency scope from one to the other via ContributesBinding will end up with error: [Dagger/DuplicateBindings]

interface MyClass

// Changing from `SubcomponentScope` to `AppScope` will throw an error
@ContributesBinding(SubcomponentScope::class)
class MyClassImpl : MyClass

[LandonPatmore]

Can you post the entire stack trace? When I've run into this, it means exactly what it is saying that there are multiple deps contributed to the graph. A subcomponent can see everything in it's parent scope, but not the other away around. Remember that. So if there is something contributed in both the AppScope and SubcomponentScope and something in SubcomponentScope tries to inject it, it will find it contributed in both scopes and error out.

[LandonPatmore]

If this isn't the case and there is nothing else actually contributed, it may be a gradle cache issue. Run ./gradlew clean and then re-run the build. I know that trackSourceFiles at one point caused an issue with build caches. Not sure if it has been fixed previously. So that may also be it.

[Laimiux]

I'm sorry, I don't have a stack trace right now, but it's pretty easy to reproduce by changing the binding scope from a subcomponent to a higher component. The issue is not for the case where we contribute the same binding to multiple related scopes (this is a valid compilation error). Instead, it is a caching issue, as the plugin adds a new binding without clearing the old one. While ./gradlew clean potentially works around the problem, it is highly inefficient for a big project.

[LandonPatmore]

I think that sadly is just a fact of using trackSourceFiles. Is there a reason your project has it enabled? I can definitely see how it is inefficient for a big project.