If all the methods in an @AutoValue class are getters (getFoo() or isFoo()) then consider that each one defines a property called foo rather than getFoo. The user-visible change is that those names appear in the toString() of the generated class. The generated code is also a lot less surprising in this case. That's typically visible when you do code-completion on the AutoValue_Foo constructor in an IDE.

The main motivation for this change is that we will want to support both bar(x) and setBar(x) when we add builders, and that means supporting both bar() and getBar() as setters.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=78161706
Remove a stray reference to AutoValueBuilderProcessor from a test. Since AutoValueBuilderProcessor is @GoogleInternal, this causes open-sourcing to break.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=78455738
Migrate off of deprecated Truth methods

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=78468371
Subvert Apache Velocity's attempt to spray logging on anything prepared to listen.
https://github.com/google/auto/issues/151
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79205227
Defer processing of an @AutoValue class with missing types, and attempt to handle it in a later annotation processing round, when those types may have come into existence.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79467609
Migrate assert_() users to new Truth shortcut:
assert_().withFailureMessage(msg) -> assertWithMessage(msg)

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79695473
In AutoValue, add a test that checks that having a non-abstract method that is not a getter does not prevent considering that the AutoValue class is using the getFoo convention (and therefore naming properties foo rather than getFoo).
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81267916
In the AutoValue README, document the newish behaviour whereby a method called getFoo() can define a property called foo.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81280407
Actually test what the previous code intended to test but didn't (as far as I can see). The intention was to verify that the properties were named using the getter convention. Just using one of the getters doesn't do this (again, as far as I can see). We need to assert the behaviour of toString, like testGetters() and testNotGetters() do.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81327546
Check whether an @AutoValue class contains an @AutoValue.Builder class or interface, and check the contents of that class or interface for correctness if so.

This code does not yet do anything if there is an @AutoValue.Builder; it just validates the builder for correctness. Later CLs will add the code-generation logic.

The property foo can be defined by either foo() or getFoo() in the @AutoValue.Builder class. The logic here recognizes both possibilities, but requires the setter method to be called foo(x) in both cases. A later change will allow setFoo(x) as an alternative, if all the methods in the builder follow that naming scheme.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81625256
Use truth snapshot until truth >.24 is released
Ignore dependency-reduced pom spam
Merge pull request #165 from google/moe_writing_branch_from_449e92e4a7f035483fb938a689e286da8af749d2

Moe writing branch from 449e92e4a7f035483fb938a689e286da8af749d2