Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide correct type names for unresolved types instead of error.UnresolvedCla$$ #24

Closed
2 of 3 tasks
Jeffset opened this issue Mar 13, 2023 · 0 comments · Fixed by #25
Closed
2 of 3 tasks

Provide correct type names for unresolved types instead of error.UnresolvedCla$$ #24

Jeffset opened this issue Mar 13, 2023 · 0 comments · Fixed by #25
Labels
backend:kapt Related to KAPT backend backend:ksp Related to KSP backend enhancement New feature or request
Milestone

Comments

@Jeffset
Copy link
Collaborator

Jeffset commented Mar 13, 2023

Currently Yatagan yields fake error.UnresolvedCla$$ stub name for every unresolved type. This is the case for both KSP and KAPT.

This is the uniformized behavior introduced because:

  1. KSP doesn't provide real unresolved type name at all, only generic <ERROR TYPE> string can be obtained
  2. KAPT requires correctErrorTypes option to be set, otherwise it provides error.NonExistentClass.

So, Yatagan detects those cases and provides error.UnresolvedCla$$ for every backend.

But this is really not an acceptable behavior, as sometimes there's no way to identify what types are actually missing/unresolved, if they are not used in hand-written code though are missing from the compilation classpath (typically when users use implementation instead of api in Gradle).

So there's actually several problems here:

  1. No names for unresolved/missing types at all.
  2. Yatagan doesn't explicitly check for error types in graphs, and may even be able to generate code with them. The code will then fail to compile, leaving the user with syntactic errors concerning error.UnresolvedCla$$ and with no info on what those types actually are and from where they are referenced from.

In order to support error type names in KSP, the google/ksp#1232 needs to be resolved first.
Support from the KAPT backend can be added already, but there's no way to test this, as correctErrorTypes option is inaccessible in room-compile-testing, so the issue https://issuetracker.google.com/u/2/issues/248552462 has to be resolved for that.

Yatagan error types detection can (and should) be implemented now, nothing blocks it.

  1. Implement error type detection in validation pipeline (in order to provide the user with the info on where the unresolved types are referenced)
  2. Maybe implement correct error types with KAPT backend (no test coverage possible though?)
  3. Wait for KSP support for error type names and add it later.
@Jeffset Jeffset added enhancement New feature or request backend:ksp Related to KSP backend backend:kapt Related to KAPT backend labels Mar 13, 2023
@Jeffset Jeffset added this to the 1.2.0 milestone Mar 13, 2023
@Jeffset Jeffset linked a pull request Mar 14, 2023 that will close this issue
Jeffset added a commit that referenced this issue Mar 31, 2023
Bump room-compiler-processing-testing to 2.6.0-alpha
 which includes `correctErrorTypes` fix for testing.
 See #24 for more info.

Remove google-auto `BasicAnnotationProcessor` harness, as
 all it does is reports unresolved types, which yatagan reports
 by its own means.

Theoretically, this completely removes support for multi-round
 processing. In practice the support was broken from the very beginning
 and yatagan doesn't intend to support it
 as it slows the build and, obviously, doesn't make sense to use
 with reflection backend.

Fix the `invalid-component-creator` test as it contained
 non-deterministic behavior (the errors reported depended on
 the inner class declaration order, which currently is not forced
 to be the same across backends).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:kapt Related to KAPT backend backend:ksp Related to KSP backend enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant