build(deps): bump hilt from 2.52 to 2.53

[dependabot]

Bumps hilt from 2.52 to 2.53.
Updates com.google.dagger:hilt-android from 2.52 to 2.53

Release notes

Sourced from com.google.dagger:hilt-android's releases.

Dagger 2.53

Potentially breaking changes:

@Binds methods now requires explicit nullability

New: @Binds methods must explicitly declare nullability (previously we tried to infer it from the parameter). This change aligns the nullability behavior of @Binds with how nullability is treated elsewhere in Dagger by requiring it to be explict at the request and declaration sites. (4941926c5)

Suggested fix: If you get a failure due to this change, add the proper nullability to your @Binds method/parameter. For example:

@Module
interface MyModule {
-    @Binds fun bindToNullableImpl(impl: FooImpl): Foo
+    @Binds fun bindToNullableImpl(impl: FooImpl?): Foo?
}

Scopes are now banned on @Binds that delegate to production implementations.

New: Scoping an @Binds method that delegates to an @Produces implementation is not allowed. The scope was ignored anyway because production bindings are implicitly scoped. (03b237ff2)

Suggested fix: Remove the scope annotation (since the scope was ignored, this should not be a functional change).

@Module
interface MyModule {
-    @ProductionScoped
     @Binds fun bindToProductionImpl(impl: FooImpl): Foo
}

@JvmSuppressWildcards now required on multibound map requests in KSP.

New: When requesting a multibound map, users must include @JvmSuppressWildcards on the map's value, e.g. Map<K, @JvmSuppressWildcards V>. Note that this has always been the behavior in KAPT, but due to a bug in the KSP implementation we accidentally matched the request without @JvmSuppressWildcards.

Suggested fix: Unfortunately, this means users may need to add back @JvmSuppressWildcards for multibound map requests. At the moment, KSP doesn't provide a way to determine the Kotlin type is actually assignable to Map<K, V> without @JvmSuppressWildcards at compile time, and without this check users could hit runtime failures when Dagger tries to cast the type to the users type.

class MyClass
</tr></table> 

... (truncated)

Commits

• 649eed5 2.53 release
• 369bbc6 [Refactor]: Move members injection optimization into its RequestRepresentation.
• 841d765 Internal changes
• 2d75be9 Internal changes
• 4046f2c [Refactor]: Change FrameworkField#create() to better align with the XPoet m...
• 9fe4824 Internal changes
• fdbc63e [Refactor]: Move ProvisionMethods#create()/InjectionSiteMethods#create() ...
• 2b84e57 Kotlin compiler update to 2.0.21, prework.
• fe811e1 Kotlin compiler update to 2.0.21, prework.
• 6b183f8 Support requesting Jakarta Provider types.
• Additional commits viewable in compare view

Updates com.google.dagger:hilt-android-compiler from 2.52 to 2.53

Release notes

Sourced from com.google.dagger:hilt-android-compiler's releases.

Dagger 2.53

Potentially breaking changes:

@Binds methods now requires explicit nullability

New: @Binds methods must explicitly declare nullability (previously we tried to infer it from the parameter). This change aligns the nullability behavior of @Binds with how nullability is treated elsewhere in Dagger by requiring it to be explict at the request and declaration sites. (4941926c5)

Suggested fix: If you get a failure due to this change, add the proper nullability to your @Binds method/parameter. For example:

@Module
interface MyModule {
-    @Binds fun bindToNullableImpl(impl: FooImpl): Foo
+    @Binds fun bindToNullableImpl(impl: FooImpl?): Foo?
}

Scopes are now banned on @Binds that delegate to production implementations.

New: Scoping an @Binds method that delegates to an @Produces implementation is not allowed. The scope was ignored anyway because production bindings are implicitly scoped. (03b237ff2)

Suggested fix: Remove the scope annotation (since the scope was ignored, this should not be a functional change).

@Module
interface MyModule {
-    @ProductionScoped
     @Binds fun bindToProductionImpl(impl: FooImpl): Foo
}

@JvmSuppressWildcards now required on multibound map requests in KSP.

New: When requesting a multibound map, users must include @JvmSuppressWildcards on the map's value, e.g. Map<K, @JvmSuppressWildcards V>. Note that this has always been the behavior in KAPT, but due to a bug in the KSP implementation we accidentally matched the request without @JvmSuppressWildcards.

Suggested fix: Unfortunately, this means users may need to add back @JvmSuppressWildcards for multibound map requests. At the moment, KSP doesn't provide a way to determine the Kotlin type is actually assignable to Map<K, V> without @JvmSuppressWildcards at compile time, and without this check users could hit runtime failures when Dagger tries to cast the type to the users type.

class MyClass
</tr></table> 

... (truncated)

Commits

• 649eed5 2.53 release
• 369bbc6 [Refactor]: Move members injection optimization into its RequestRepresentation.
• 841d765 Internal changes
• 2d75be9 Internal changes
• 4046f2c [Refactor]: Change FrameworkField#create() to better align with the XPoet m...
• 9fe4824 Internal changes
• fdbc63e [Refactor]: Move ProvisionMethods#create()/InjectionSiteMethods#create() ...
• 2b84e57 Kotlin compiler update to 2.0.21, prework.
• fe811e1 Kotlin compiler update to 2.0.21, prework.
• 6b183f8 Support requesting Jakarta Provider types.
• Additional commits viewable in compare view

Updates com.google.dagger.hilt.android from 2.52 to 2.53

Release notes

Sourced from com.google.dagger.hilt.android's releases.

Dagger 2.53

Potentially breaking changes:

@Binds methods now requires explicit nullability

New: @Binds methods must explicitly declare nullability (previously we tried to infer it from the parameter). This change aligns the nullability behavior of @Binds with how nullability is treated elsewhere in Dagger by requiring it to be explict at the request and declaration sites. (4941926c5)

Suggested fix: If you get a failure due to this change, add the proper nullability to your @Binds method/parameter. For example:

@Module
interface MyModule {
-    @Binds fun bindToNullableImpl(impl: FooImpl): Foo
+    @Binds fun bindToNullableImpl(impl: FooImpl?): Foo?
}

Scopes are now banned on @Binds that delegate to production implementations.

New: Scoping an @Binds method that delegates to an @Produces implementation is not allowed. The scope was ignored anyway because production bindings are implicitly scoped. (03b237ff2)

Suggested fix: Remove the scope annotation (since the scope was ignored, this should not be a functional change).

@Module
interface MyModule {
-    @ProductionScoped
     @Binds fun bindToProductionImpl(impl: FooImpl): Foo
}

@JvmSuppressWildcards now required on multibound map requests in KSP.

New: When requesting a multibound map, users must include @JvmSuppressWildcards on the map's value, e.g. Map<K, @JvmSuppressWildcards V>. Note that this has always been the behavior in KAPT, but due to a bug in the KSP implementation we accidentally matched the request without @JvmSuppressWildcards.

Suggested fix: Unfortunately, this means users may need to add back @JvmSuppressWildcards for multibound map requests. At the moment, KSP doesn't provide a way to determine the Kotlin type is actually assignable to Map<K, V> without @JvmSuppressWildcards at compile time, and without this check users could hit runtime failures when Dagger tries to cast the type to the users type.

class MyClass
</tr></table> 

... (truncated)

Commits

• 649eed5 2.53 release
• 369bbc6 [Refactor]: Move members injection optimization into its RequestRepresentation.
• 841d765 Internal changes
• 2d75be9 Internal changes
• 4046f2c [Refactor]: Change FrameworkField#create() to better align with the XPoet m...
• 9fe4824 Internal changes
• fdbc63e [Refactor]: Move ProvisionMethods#create()/InjectionSiteMethods#create() ...
• 2b84e57 Kotlin compiler update to 2.0.21, prework.
• fe811e1 Kotlin compiler update to 2.0.21, prework.
• 6b183f8 Support requesting Jakarta Provider types.
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)