Dagger: Possible error reporting inconsistency when using @Binds vs @Provides

[peter-tackage]

When a module illegally provides multiple bindings for the same type using @Binds if any of the duplicate binding method's dependencies cannot be satisfied, no error is generated and whichever binding method whose dependencies can be satisfied is then provided. Whereas when using @Provides a compilation error (xyz class is bound multiple times) is generated.

This strikes me as inconsistent, I would expect that when using @Bind that any attempt to use multiple bindings for the same type should report an error, regardless if the dependencies can be satisfied (as is the behavior for @Provides).

See this repo for a demonstration.

Using Dagger 2.6.

[ronshapiro]

Eeks, that's bad. I'm looking into it.

Here's a boiled down example:

@Component(modules = M.class)
interface C {
  BoundTwice boundTwice();
}

@Module
abstract class M {
  @Provides @Named("impl") static BoundTwice provideImpl() {
    return new BoundTwice() {};
  }

  /**/
  @Binds abstract BoundTwice bindImpl(@Named("impl") BoundTwice impl);
  @Binds abstract BoundTwice notResolved(@Named("not resolved") BoundTwice notResolved);
  /*/
  @Provides static BoundTwice bindImpl(@Named("impl") BoundTwice impl) {
    return impl;
  }
  @Provides static BoundTwice notResolved(@Named("not resolved") BoundTwice notResolved) {
    return new BoundTwice() {};
  }
  /**/

}

interface BoundTwice {}

[ronshapiro]

removing one of the * from the line above the first @Binds allows you to alternate between @Binds and @Provides

[ronshapiro]

I have a fix out for review internally (cl/129465311) - hope to get it out soon! Thanks for reporting!