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

Preserve type annotations better after type rewriting. #1704

Merged
1 commit merged into from
Feb 10, 2024
Merged

Conversation

copybara-service[bot]
Copy link
Contributor

@copybara-service copybara-service bot commented Jan 30, 2024

Preserve type annotations better after type rewriting.

Sometimes we rewrite types, for example to see that the return type of T foo() in Bar<T> is actually String in class Baz implements Bar<String>. Unfortunately rewriting types using the javax.lang.model API leads to the loss of any type annotations they originally had. If we had @Nullable T foo() it would become just String foo() rather than @Nullable String foo(). So we introduce a new class AnnotatedTypeMirror that tracks both the original type (with its annotations) and the rewritten type (without them), so we can combine the two when writing types into the generated code.

This is not a fully general solution. We will indeed reconstruct @Nullable String in the example, but we will still lose the annotation when rewriting List<@Nullable T> as List<String>. I think the only way around that is to forgo the use of Types.asMemberOf and instead substitute type variables ourselves. That's similar to but more general than what we already do in TypeVariables.substituteTypeVariables. It is made more awkward by the lack of a way to synthesize a TypeMirror with annotations; see https://bugs.openjdk.org/browse/JDK-8174126. (We could implement TypeMirror and its subinterfaces ourselves, but the resulting objects would not work with the javax.lang.model API.)

RELNOTES=Handling of type annotations on inherited methods has been improved.

@copybara-service copybara-service bot force-pushed the test_main_602559394 branch 5 times, most recently from 5aad652 to 32cdfa8 Compare February 1, 2024 21:24
Sometimes we rewrite types, for example to see that the return type of `T foo()` in `Bar<T>` is actually `String` in `class Baz implements Bar<String>`. Unfortunately rewriting types using the `javax.lang.model` API leads to the loss of any type annotations they originally had. If we had `@Nullable T foo()` it would become just `String foo()` rather than `@Nullable String foo()`. So we introduce a new class `AnnotatedTypeMirror` that tracks both the original type (with its annotations) and the rewritten type (without them), so we can combine the two when writing types into the generated code.

This is not a fully general solution. We will indeed reconstruct `@Nullable String` in the example, but we will still lose the annotation when rewriting `List<@nullable T>` as `List<String>`. I think the only way around that is to forgo the use of [`Types.asMemberOf`](https://docs.oracle.com/en/java/javase/21/docs/api/java.compiler/javax/lang/model/util/Types.html#asMemberOf(javax.lang.model.type.DeclaredType,javax.lang.model.element.Element)) and instead substitute type variables ourselves. That's similar to but more general than what we already do in [`TypeVariables.substituteTypeVariables`](https://github.com/google/auto/blob/e20db259ac2d6b176e396639a7540cadec38a9aa/value/src/main/java/com/google/auto/value/processor/TypeVariables.java#L169). It is made more awkward by the lack of a way to synthesize a `TypeMirror` with annotations; see https://bugs.openjdk.org/browse/JDK-8174126. (We could implement `TypeMirror` and its subinterfaces ourselves, but the resulting objects would not work with the `javax.lang.model` API.)

RELNOTES=Handling of type annotations on inherited methods has been improved.
PiperOrigin-RevId: 605781385
@copybara-service copybara-service bot closed this pull request by merging all changes into main in 7373b98 Feb 10, 2024
@copybara-service copybara-service bot deleted the test_main_602559394 branch February 10, 2024 02:16
copybara-service bot pushed a commit that referenced this pull request Nov 25, 2024
…setters.

This handles a further case using the logic introduced by #1704.

RELNOTES=Type-use annotations such as `@Nullable` are now better preserved in generated builder setter method parameters. Previously they could be lost in some circumstances, for example with `@Nullable T`.
PiperOrigin-RevId: 699721928
copybara-service bot pushed a commit that referenced this pull request Nov 25, 2024
…setters.

This handles a further case using the logic introduced by #1704.

RELNOTES=Type-use annotations such as `@Nullable` are now better preserved in generated builder setter method parameters. Previously they could be lost in some circumstances, for example with `@Nullable T`.
PiperOrigin-RevId: 699982315
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant