| Age | Commit message (Collapse) | Author |
|---|
|
rewritten.
RELNOTES=n/a
PiperOrigin-RevId: 382304083
|
|
Previously we avoided collectors like `toImmutableList()` because of Google-internal problems where sometimes we would end up with a version of Guava that didn't include those methods. Now we have copies of the methods in `MoreStreams` so we can use those.
RELNOTES=n/a
PiperOrigin-RevId: 381898090
|
|
Previously it worked, but only if the builder interface also had a setter for the property. Otherwise you would get an exception because the template referenced the `$toBuilderMethods` variable, which was undefined.
RELNOTES=Fixed a bug with AutoBuilder and property builder methods.
PiperOrigin-RevId: 381330964
|
|
reformatting is excluded.
RELNOTES=n/a
PiperOrigin-RevId: 377145832
|
|
usages with auto-common alternatives.
This fixes an issue that occurs when the Android flavor of Guava somehow finds its way onto the processor class path and gets classloaded instead of the server Guava. The ideal solution would be to just keep the Android flavor of Guava off of the processor class path. However, it's been something that we've allowed for a while now, e.g. in Dagger, and would be difficult to start enforcing.
RELNOTES=N/A
PiperOrigin-RevId: 376926489
|
|
Resolves #1087
Fixes #1099
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/auto/pull/1099 from ZacSweers:z/metadata eb0328e9ac7772b5f811ea7d5094786ccc6d678e
PiperOrigin-RevId: 376238198
|
|
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=Introduced an UNSTABLE `@AutoBuilder` feature.
PiperOrigin-RevId: 369485151
|
|
RELNOTES=n/a
PiperOrigin-RevId: 368677272
|
|
AutoBuilder.
RELNOTES=n/a
PiperOrigin-RevId: 368507215
|
|
This change adds support for methods or constructors that throw checked exceptions, and methods that have a void return type.
RELNOTES=n/a
PiperOrigin-RevId: 368486594
|
|
A builder-getter is a method in the builder interface that lets you see what value has been set for a property of the builder. Like `@AutoValue.Builder`, the getter for a property of type `T` can return either `T` or `Optional<T>`. Trying to get a property that has not been set will provoke an exception for the former or return `Optional.empty()` for the latter.
With `@AutoValue.Builder`, a builder-getter method corresponds to a method with the same signature in the `@AutoValue` class. Here, a builder-getter method corresponds to a parameter with the same name and type, except that the builder-getter for parameter `foo` can be either `foo()` or `getFoo()`.
RELNOTES=n/a
PiperOrigin-RevId: 368222631
|
|
Obviously Java code can't have such parameter names, but Kotlin code might, for example.
RELNOTES=n/a
PiperOrigin-RevId: 368044975
|
|
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
|
|
There can be more than one visible constructor (or static method) in the `ofClass` class. This change adds some ad-hoc logic to pick the right one by matching the names of its parameters against the methods in the `@AutoBuilder` interface.
There is some duplication of knowledge between this new logic and the existing `BuilderMethodClassifier` logic. Another approach would be to try `BuilderMethodClassifier` for _each_ visible constructor and retain whichever one it works for. The concern there, though, is that if the user code is wrong it will be hard to produce succinct error messages explaining why. With the approach here, we can show for each constructor which parameters did not match (in a later change).
Also, the problem where we didn't handle a property called aString very well has been fixed, so adjust tests accordingly.
RELNOTES=n/a
PiperOrigin-RevId: 367237991
|
|
the `callMethod`.
Previously, for convenience, we reused the logic from AutoValue of examining abstract getter methods in the built type. But AutoBuilder is not specified to do that. Instead, every parameter of the target constructor or `callMethod` method defines the name and type of a property, and the builder must specify a way to set that property.
RELNOTES=n/a
PiperOrigin-RevId: 367056519
|
|
subclass.
This prepares the sharing of `BuilderMethodClassifier` between AutoValue and AutoBuilder. The logic for handling builders is substantially the same between the two. The main difference is that AutoValue properties come from abstract getter methods in the `@AutoValue` class, while AutoBuilder properties come from the parameters of the constructor or method that will be called. Before this change we had `ExecutableElement` instances that were the getter methods. Now we have `Element` instances that are refined as `ExecutableElement` in the new subclass `BuilderMethodClassifierForAutoValue`. In a later step we will introduce `BuilderMethodClassifierForAutoBuilder` where each `Element` will each be a `VariableElement` representing the property parameter.
Earlier versions of this change ran into confusion between "original" and "rewritten" property types, so `BuilderMethodClassifier` now makes that distinction more explicit.
RELNOTES=n/a
PiperOrigin-RevId: 366888706
|
|
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
|
|
RELNOTES=n/a
PiperOrigin-RevId: 363493391
|
|
RELNOTES=n/a
PiperOrigin-RevId: 363472352
|
|
if any command it runs fails.
RELNOTES=n/a
PiperOrigin-RevId: 363468275
|
|
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
|
|
Previously, a property builder for `abstract ImmutableSet<String> foos()` had to look like `abstract ImmutableSet.Builder<String> foosBuilder()`. For `ImmutableSortedSet`, this meant that you could only construct a builder using `ImmutableSortedSet.naturalOrder()`. Now, if you have `abstract ImmutableSortedSet<String> foos()` you can optionally write `abstract ImmutableSortedSet.Builder<String> foosBuilder(Comparator<String> comparator)`. This works because `ImmutableSortedSet.Builder<T>` has a constructor `ImmutableSortedSet.Builder(Comparator<T>)`.
This change is closely based on https://github.com/google/auto/pull/983 by Paweł Łabaj. I adjusted the formatting slightly, renamed a couple of methods, and reworded the new text in the user guide. The only substantive change is that I removed the special knowledge of the static `orderedBy` method (from `ImmutableSortedSet` and `ImmutableSortedMap`) since the builder constructor works just as well in those cases.
Closes https://github.com/google/auto/pull/983.
Fixes https://github.com/google/auto/issues/984.
RELNOTES=AutoValue property builders can now have a single parameter which is passed to the constructor of the new builder.
PiperOrigin-RevId: 358583454
|
|
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
|
|
Normally we follow the JavaBeans specification, which has special rules for properties that begin with more than one capital, like the `OAuth` implied by `getOAuth()` here. That means that the unprefixed setter should be spelled `OAuth(T)`. That's obviously obscure and unsettling, so we add logic to allow the setter to be either `OAuth(T)` or `oAuth(T)` in this case. We already have logic for the opposite case, where the getter is `oAuth()` and the setter is `setOAuth(T)`.
Fixes https://github.com/google/auto/issues/565.
RELNOTES=Avoid surprising behaviour when getters are prefixed and setters are not, and a property name begins with two capital letters.
PiperOrigin-RevId: 351188819
|
|
`.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
|
|
RELNOTES=N/A
PiperOrigin-RevId: 338314094
|
|
RELNOTES=N/A
PiperOrigin-RevId: 338296766
|
|
Annotation claiming is a misfeature and we already stopped doing it years ago in AutoValueProcessor. It's an oversight that we didn't do it for these processors at the same time.
Also apply some automated code-fix suggestions.
RELNOTES=AutoAnnotationProcessor and AutoServiceProcessor no longer claim their annotations.
PiperOrigin-RevId: 337750292
|
|
the names and types of the `@AutoAnnotation` method parameters.
RELNOTES=n/a
PiperOrigin-RevId: 332000022
|
|
RELNOTES=`@AutoAnnotation` instances are now serializable.
PiperOrigin-RevId: 331666372
|
|
PiperOrigin-RevId: 326930055
|
|
RELNOTES=Fully Qualify @Override to avoid name conflicts
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=323461838
|
