Bump hilt-android-compiler from 2.39.1 to 2.42

[dependabot[bot]]

Bumps hilt-android-compiler from 2.39.1 to 2.42.

Release notes

Sourced from hilt-android-compiler's releases.

Dagger 2.42

What’s new in Dagger

Potentially breaking changes

As of this release, Dagger’s generated class will no longer extend the user-defined @Component annotated class (885b16dcf). This change was done to improve build times in certain scenarios by avoiding a known javac bottleneck. However, it may also be a breaking change for some users. For example

// This will fail as of Dagger version 2.42
DaggerMyComponent component = DaggerMyComponent.create();
// Do this instead:
MyComponent component = DaggerMyComponent.create();

For migration purposes, we’ve added a temporary javac flag that can be used to re-enable the legacy behavior (the flag is disabled by default).

-Adagger.generatedClassExtendsComponent=ENABLED

This flag will be removed in a future version of Dagger.

What’s new in Hilt

Bug fixes

• Fix two issues (e3d446873):
  1. matchingFallbacks being ignored work with Hilt.
  2. Hilt causing jetifier to execute twice.
• Allow Hilt view constructor to contain non-declared types. (dc76e82c0)
• Fix #3222. Generated fragment code previously would cause a Lint issue around LayoutInflater.from(). (850fc8474)
• Fix #3329 where modules in a package with non-standard capitalization could cause an error in the Hilt Gradle Plugin. (029fe5702 and 329915f5f)

Dagger 2.41

What’s New In Dagger

Potentially Breaking Changes

• This release fixes a recently noticed, but long-standing bug (#3136) where Dagger’s processors may silently miss a scope/qualifier on a binding if the scope/qualifier annotation is unresolvable (i.e. it is not on the classpath).
  
  Dagger will now prefer to fail the build if there are any unresolvable annotations present where a scope/qualifier is allowed. While Dagger does its best to avoid failing the build for non-scope/qualifier annotations, in general it’s not possible to tell if an annotation is a scope/qualifier unless its type is resolvable -- thus, Dagger may fail on non-scope/qualifier annotations as well.
  
  If these changes break your build, we recommend first trying to fix the breakage by adding the appropriate missing dependencies to your build (in most cases the error message should tell you exactly what type is missing). Although not recommended, you can revert back to the old behavior using the compiler option -Adagger.strictSuperficialValidation=DISABLED; however, this option will be removed in a future release. If the breakage is specifically due to the validation of transitive component dependencies, you may choose to disable that validation using -Adagger.validateTransitiveComponentDependencies=DISABLED. If the breakage is specifically due to androidx.hilt:hilt-lifecycle-viewmodel you will need to migrate to the native Hilt API (see google/dagger#3257).

• This release fixes an accidental regression (introduced in Dagger version 2.39) that allowed requesting a raw @Inject constructor type which was previously not allowed (a61aa50c8).
  
  We expect breakages due to this issue to be relatively rare and easy to fix -- just replace the raw type with the proper parameterized type.

... (truncated)

Commits

• 46fc050 2.42 release
• c3f1944 Update kotlin-metadata-jvm to 4.0 which support reading metadata from upcomin...
• b60b8e5 Remove usages of .java(), toJavac(), and toXProcessing() which were nee...
• e793595 Internal Changes.
• d14a3d6 Manually pass in application instance when creating EarlySingletonComponent.
• b0aa9f1 Replace javac implementation of XProcessingEnv#isAssignable() with XProcessin...
• dfab36d Improve the error message for conflicting entry points.
• 0dfbcaa [Refactor] Move CompositeBindingGraphValidator into bindinggraphvalidation pa...
• 1a01575 Fix O(N^2) performance issue when determining declaration order.
• 75a79c0 Update the XProcessing jar
• 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 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)

[dependabot[bot]]

Superseded by #312.