| Age | Commit message (Collapse) | Author |
|---|
|
rewritten.
RELNOTES=n/a
PiperOrigin-RevId: 382304083
|
|
RELNOTES=n/a
PiperOrigin-RevId: 377297134
|
|
reformatting is excluded.
RELNOTES=n/a
PiperOrigin-RevId: 377145832
|
|
Resolves #1087
Fixes #1099
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/auto/pull/1099 from ZacSweers:z/metadata eb0328e9ac7772b5f811ea7d5094786ccc6d678e
PiperOrigin-RevId: 376238198
|
|
RELNOTES=n/a
PiperOrigin-RevId: 375814417
|
|
it is available.
More exactly, we will generate `equals(@Nullable Object)` if we know a `@Nullable` annotation. We know a `@Nullable` annotation if one is mentioned in a method parameter or return type of the `@AutoValue` [etc] class; this was already true before this CL. What's new is that we also know a `@Nullable` annotation if one is available in the compilation environment and matches the one we expect. That in turn is `@org.jspecify.nullness.Nullable` by default, but can be overridden or suppressed with a new `-A` option.
We also insert `@Nullable` for `@AutoAnnotation` implementations, though currently we don't have logic to find one that might be referenced from methods.
RELNOTES=n/a
PiperOrigin-RevId: 375811563
|
|
to understand.
The new code is more verbose than the old, since it has two null checks for every property (when there is more than one required property). The second check will only be executed when at least one property is missing and we are about to throw an exception. The extra checks also don't happen when compiling without identifiers, as is typically the case in code-size-sensitive environments like Android.
RELNOTES=Generated builder code is now slightly friendly to null-analysis.
PiperOrigin-RevId: 374652915
|
|
Previously it was erroneously using the package from the `ofClass` class. That's often the same package, but when it isn't the generated code was wrong.
RELNOTES=n/a
PiperOrigin-RevId: 371342620
|
|
for complex types.
The problem is that the generated code can include nested lambdas. If an inner lambda uses the same identifier for a parameter as an outer one, that's a kind of hiding that the Java compiler doesn't allow. So we add a method to `SerializerFactory` that generates unique identifiers.
RELNOTES=Fixed a problem where `@SerializableAutoValue` could generate incorrect code for complex types.
PiperOrigin-RevId: 370078937
|
|
This adds the offending method name to the `getterMustMatch` error message. This makes it much less ambiguous to debug. e.g. `Method createdAt does not correspond to a property of MyBuilder`.
Fixes #1067
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/auto/pull/1067 from ZekeSnider:add-method-name-in-error 2cfd42a0c32ee57320d58a4823779cdf295d6dea
PiperOrigin-RevId: 369989868
|
|
RELNOTES=n/a
PiperOrigin-RevId: 368041526
|
|
Almost all errors in that class should now be covered by tests in both `AutoValueCompilationTest` and `AutoBuilderCompilationTest`. The exception is coverage of builder getters, which AutoBuilder does not yet support fully.
RELNOTES=n/a
PiperOrigin-RevId: 367706511
|
|
I'm working through the error messages in `BuilderMethodClassifier` and adding tests as I go. More to come.
Also add a test of property-builder methods in `AutoBuilderTest`. This can't yet handle type variables because AutoBuilder doesn't support them properly yet.
RELNOTES=n/a
PiperOrigin-RevId: 367687734
|
|
These correspond to errors in `AutoBuilderProcessor`. Further tests will check for errors in `BuilderMethodClassifier`.
RELNOTES=n/a
PiperOrigin-RevId: 367646674
|
|
Up until now, `@AutoBuilder` builders, like `@AutoValue.Builder` builders, only ever invoked constructors from their `build()` method. But AutoBuilder is specified to apply also to static methods. This introduces a new distinction which we did not have before, between the type containing the executable to invoke (up until now always a constructor) and the type that that executable produces (which for a constructor was obviously the same type).
RELNOTES=n/a
PiperOrigin-RevId: 367442955
|
|
Unfortunately it appears that JDK versions before 11 have a bug where the compiler won't report parameter names to annotation processors if the parameters are in code that has been compiled separately. This is true even if the code is compiled with `-parameters`. It might not happen always, but it does happen for the Kotlin data classes we are testing against. So we exclude the test that uses them when running with JDK version < 11.
Also add a missing `-A` flag that is needed for the `record` compilation test, and only run that test with JDK ≥ 16, where records are no longer a preview feature.
RELNOTES=n/a
PiperOrigin-RevId: 366807595
|
|
This is not ready for use yet.
For now, it only supports constructor invocation, not static methods; it does not handle overloads correctly (it requires there to be a maximal constructor and uses that); it has problems with case when getters have names like `getAString`. There are other problems.
RELNOTES=n/a
PiperOrigin-RevId: 366603722
|
|
`DeclaredType`.
The old logic was unnecessarily tortuous, extracting the `DeclaredType` for the `@Nullable` annotation we found, then later synthesizing a new `AnnotationMirror` for that type. We can just use the original `AnnotationMirror`.
Later we will probably introduce logic to use the [JSpecify](http://jspecify.org) `@Nullable` if it is available and if the `@AutoValue` class doesn't mention its own `@Nullable`. At that point we can go back to synthesizing an `AnnotationMirror`, but only for that particular case.
RELNOTES=n/a
PiperOrigin-RevId: 364834935
|
|
that `@Nullable` to the parameter of `equals(Object)`.
This only works for `TYPE_USE` annotations, which is what everybody should be using these days.
RELNOTES=The parameter of `equals(Object)` is annotated with `@Nullable` if any method signature mentions `@Nullable`.
PiperOrigin-RevId: 364642711
|
|
generated subclasses.
Previously the subclasses did not have an explicit `serialVersionUID`, so their implicit ones were likely to change if any details of the code-generation changed.
This change BREAKS SERIAL COMPATIBILITY for `@AutoOneOf` classes that had an explicit `serialVersionUID`.
Also, don't bother generating the shared `Parent_` class in the degenerate case of an `@AutoOneOf` class with no alternatives.
These changes reduce the number of warnings from `CompileWithEclipseTest` from 11 to 3.
RELNOTES=If an `@AutoOneOf` class has a `serialVersionUID` this is now copied to its generated subclasses. THIS BREAKS SERIAL COMPATIBILITY for `@AutoOneOf` classes with explicit `serialVersionUID` declarations, though those were already liable to be broken by arbitrary changes to the generated AutoOneOf code.
PiperOrigin-RevId: 364387942
|
|
There were 133 warnings, which made it hard to find any errors or unexpected warnings that might crop up. With this change there are 11 warnings, which we might later be able to reduce further.
Also fix potentially-raw types in an unusual case, `equals` for generic `@AutoValue` classes with primitive array fields.
RELNOTES=n/a
PiperOrigin-RevId: 364357181
|
|
RELNOTES=n/a
PiperOrigin-RevId: 363994601
|
|
The background here is that AutoValue and its cousins produce code using Velocity templates, and then run a reformatter over the result to fix up various whitespace problems. That works fine except that it's very difficult to manage indentation in templates. For example, given something like this:
```
${class}(
#foreach ($p in $properties)
$p.type $p.name #if ($foreach.hasNext) , #end
#end
) {
```
Velocity deletes newlines after directives like `#foreach`, so we will get the spaces before `#foreach` at the start of the first parameter line and we'll get the spaces before `#end` at the start of the line beginning with `)`. This particular case can be fixed by adding a newline after the `#foreach` and after the `#end`. But it's very tricky to manage all these extra blank lines.
What this change does is to replace whatever initial space comes out of the template with the correct indentation that we compute. That should allow us to make the templates a lot more readable by deleting the weird blank lines. The example above should work correctly without needing them.
RELNOTES=n/a
PiperOrigin-RevId: 363340310
|
|
representation.
Also fix a property name that was renamed.
RELNOTES=n/a
PiperOrigin-RevId: 361578257
|
|
AutoValue types.
RELNOTES=Add `@ToPrettyString` for generating pretty `String` versions for AutoValue types.
PiperOrigin-RevId: 361402592
|
|
subclass generated by the `@Memoized` extension.
We already do this for the main `@AutoValue` subclass but until now we did not do it for this standard extension.
Also add some streamy goodness to the `MemoizedExtension` code.
RELNOTES=AutoValue now copies annotations from type parameters of an `@AutoValue` class to the subclass generated by the `@Memoized` extension.
PiperOrigin-RevId: 354373702
|
|
RELNOTES=n/a
PiperOrigin-RevId: 353066772
|
|
`.toBuilderMethods()` can be inherited.
This change addresses cases like this:
```java
interface Parent<BuilderT> {
BuilderT toBuilder();
interface Builder<BuilderT, BuiltT> {",
BuilderT setThing(String x);",
BuiltT build();",
}
}
@AutoValue abstract class Foo implements Parent<Foo.Builder> {
@AutoValue.Builder
abstract static class Builder implements Parent.Builder<Builder, Foo> {}
}
```
Previously, there would be two problems with this. First, inheriting `toBuilder()` like this didn't work at all, because its return type is `BuilderT` and not `Foo.Builder`. Now we correctly interpret the inherited return type in the context of `Foo`. Second, in `BuilderContext.buildMethod()` we were looking for methods returning `Foo`, and again this failed because the inherited `build()` method returns `BuiltT`. The fix in both cases is to use `Types.asMemberOf` to determine the correct return type in context.
Fixes https://github.com/google/auto/issues/933.
RELNOTES=The methods returned by `BuilderContext.buildMethod()` and `.toBuilderMethods()` can be inherited.
PiperOrigin-RevId: 342670816
|
|
SimpleServiceLoader.
Updating the compile-testing version revealed a bug in AutoValue. If the same jar is present more than once in the class path (perhaps in different versions), then we get `META-INF/services` contributions from both. That could lead to us instantiating the same AutoValueExtension more than once. The bug has been fixed by uniquifying the list of classes before instantiating them.
We specifically saw this bug because compile-testing now has a dependency on AutoValue, which meant that that AutoValue was in the classpath when compiling tests, in addition to the version of AutoValue being tested.
RELNOTES=Fixed a bug which could lead to the same AutoValue extension being run more than once.
PiperOrigin-RevId: 339463884
|
|
the names and types of the `@AutoAnnotation` method parameters.
RELNOTES=n/a
PiperOrigin-RevId: 332000022
|
|
RELNOTES=`@AutoAnnotation` instances are now serializable.
PiperOrigin-RevId: 331666372
|
|
RELNOTES=Fully Qualify @Override to avoid name conflicts
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=323461838
|
|
Fixes https://github.com/google/auto/issues/849. Closes https://github.com/google/auto/pull/850.
RELNOTES=Drop unnecessary parentheses in AutoAnnotation `equals` and `hashCode` methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=312284275
|
|
undefined return type or parameter type. This avoids problems in certain cases where other annotation processors will generate the currently-undefined type.
Fixes https://github.com/google/auto/issues/847.
RELNOTES=Fixed a problem when an `@AutoValue` class references types that are generated by other annotation processors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=312172526
|
|
Since it is a built-in extension, and since AutoValue itself only describes
itself as isolating if all extensions are, this omission meant that the
presence of AutoValue disabled incremental builds in Gradle.
Add a test to ensure that we don't forget this with future extensions.
Fixes https://github.com/google/auto/issues/844.
RELNOTES=AutoValue is once again "isolating" for Gradle incremental compilation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=310610697
|
|
In particular, the use of `onLineContaining` instead of `onLine` makes for much clearer compilation-error tests.
Some tests now assert `.succeededWithoutWarnings()` where previously they just asserted that compilation succeeded. I checked that this change passes on Travis, which historically has discovered warnings that we didn't see locally. It doesn't appear to be necessary to add `-Xlint:-processor` or the like.
Also remove some unneeded `throws Exception` clauses from test methods, and one unused private method in a test.
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=308672643
|
|
If you have an `@AutoValue` class `Foo` with a property `Bar bar()` and `Foo.Builder` has a method `BarBuilder barBuilder()`, then we previously allowed that, provided we knew how to make a `BarBuilder` (for example by calling `Bar.builder()`). But if, in addition, `Foo` has its own `toBuilder()` method, then we also need to be able to make a `BarBuilder` out of an existing `Bar`, because if you call `Foo.Builder builder = foo1.toBuilder()` then the builder returned by `builder.barBuilder()` must start off with the contents of `foo1.bar()`. Previously we allowed that when `Bar` had a method `BarBuilder toBuilder()`. We also had a special case for Guava classes like `ImmutableList`. `ImmutableList` doesn't have a `toBuilder()` method, but you can make an `ImmutableList.Builder` out of an `ImmutableList` by starting with an empty `ImmutableList.Builder` and calling `addAll(theImmutableList)`. The change here generalizes that special case: it will work if the `BarBuilder` class has a method `addAll` or `putAll` that can accept an argument of type `Bar`. `ImmutableList.Builder<E>` has a method `addAll(Iterable<? extends E>)` and you can pass an `ImmutableList<E>` to that method, so we still accept `ImmutableList.Builder<T> barBuilder()`. But we now also accept any other class that qualifies.
Fixes https://github.com/google/auto/issues/794.
RELNOTES=Generalized the logic for determining if we can make a BarBuilder out of a Bar. For example, if your `@AutoValue` class `Foo` has a property `IntList ints()`, then your builder can have `IntListBuilder intsBuilder()`, where `IntListBuilder` is your own type, and this will work even if there is a `Foo.toBuilder()` method, provided it's possible to call `IntListBuilder.addAll(IntList)`. Previously it worked, but not if there was a `Foo.toBuilder()` because we didn't know how to make `IntListBuilder` out of `IntList`.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=308628522
|
|
RELNOTES=AutoValue now gives a warning if the static builder() method is inside the @AutoValue.Builder class instead of directly in the @AutoValue class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=304683697
|
|
contains multiple properties with the same type.
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=304293379
|
|
RELNOTES=Release the SerializableAutoValue extension.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=304211473
|
|
For example if there's a type mismatch between a property getter and the
corresponding setter in a Builder, we may otherwise end up invoking an extension
with an inconsistent state. Also the generated code is likely to have compile
errors of its own, which distract from the real source of the problem.
Fixes https://github.com/google/auto/issues/809.
RELNOTES=Don't generate code or invoke extensions if AutoValue detects a problem, for example a mismatch between getters and setters.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=294552938
|
|
This allows users of AutoOneOf to not have to manually cast the value.
Before:
@SuppressWarnings("unchecked")
public static <T> MyOneOf<T> empty() {
return (MyOneOf<T>) AutoOneOf_MyOneOf.empty();
}
After:
public static <T> MyOneOf<T> empty() {
return AutoOneOf_MyOneOf.empty();
}
RELNOTES=Add type parameters to factory methods for void AutoOneOf values
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=294216002
|
|
being set is not @Nullable. We will generate code that rejects a null parameter whether or not @Nullable is present, so allowing it is just misleading users of the API.
The mirror situation, where the property is @Nullable but the setter is not, is arguably also incorrect. In that case the generated code does *not* reject a null parameter, even though we might expect it to in the absence of @Nullable on the parameter. However, changing that would surely break a lot of existing code.
Fixes https://github.com/google/auto/issues/777.
RELNOTES=It is now a compilation error if a setter method in a builder has a parameter marked @Nullable when the corresponding property is not in fact @Nullable. This already generated a NullPointerException at runtime.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=289103954
|
|
is the type after type-variable substitution. Report this type in error messages, since it may not be obvious.
(See AutoValueNotEclipseTest for an example of the problem this is fixing.)
Fix CompileWithEclipseTest so that it actually does exclude AutoValueNotEclipseTest.java from the compilation, as intended. Move the existing test within that file into AutoValueTest.java, since apparently the Eclipse bug it was provoking has been fixed. Add the test for the bug being fixed here into AutoValueNotEclipseTest.java, because it hits another Eclipse bug.
Fixes https://github.com/google/auto/issues/802.
RELNOTES=Fixed an issue with type checking of setter parameters in the presence of inheritance and generics.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=287580372
|
|
RELNOTES=Add a way for extensions to retrieve the name of the final AutoValue_Foo class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=273511598
|
|
Fixes https://github.com/google/auto/issues/421.
RELNOTES=Add an API to allow AutoValue extensions to find out about builders.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=272009461
|
|
This doesn't change the tests, but means that people looking at these tests for example of extensions won't be led astray.
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=267669692
|
|
extensions to see the true type of every property. Use it in the @Memoized extension.
RELNOTES=Add a propertyTypes() method to AutoValueExtension.Context, to allow extensions to see the true type of every property.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=267606097
|
|
See [] for more details
#TypeEqualsCleanup
RELNOTES=Suppress TypeEquals warning
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=256461683
|
|
This should mean a lot less copying in the postprocessing phase. The new version produces identical output to the old one, except that it deletes blank lines at the start of the file. I checked this by running all of AutoValue's tests with a version of Reformatter that computed the old and new forms and compared them.
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=255231424
|
