-
Notifications
You must be signed in to change notification settings - Fork 7
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
Handle AutoValue Extensions #110
Comments
More details on why this is hard. AutoValue Extensions can "consume" arbitrary abstract methods of the If a method gets consumed, then there is no corresponding setter in the generated builder. To know which methods are getting consumed in the current build, we need to know what each extension is doing. But, the extensions are run by AutoValue, which may run before or after our checker. My feeling is the best hope we have is to run the extensions ourselves to see what is getting consumed, but that would take some significant investigation / implementation, and it might not even work. |
Before, we would fail with a `RuntimeException` if we couldn't match what we thought was an AutoValue property to a corresponding setter in the builder. But, we don't currently handle AutoValue extensions (see #110), and adding full and proper handling will be pretty non-trivial. So, instead of failing for these cases, just tolerate them. Add a test case using the AutoValue Parcel extension to expose the problem, along with some stub Android classes so we don't need to pull in a full Android dependence.
Before, we would fail with a `RuntimeException` if we couldn't match what we thought was an AutoValue property to a corresponding setter in the builder. But, we don't currently handle AutoValue extensions (see #110), and adding full and proper handling will be pretty non-trivial. So, instead of failing for these cases, just tolerate them. Add a test case using the AutoValue Parcel extension to expose the problem, along with some stub Android classes so we don't need to pull in a full Android dependence.
AutoValue has extensions that can affect which methods of an
@AutoValue
type correspond to properties. See, e.g, the following comment:https://github.com/google/auto/blob/4543619f73dc94cc9a7232f340067e5bfe8ddb24/value/src/main/java/com/google/auto/value/processor/AutoValueProcessor.java#L193-L198
We need to find a way to make our AutoValue support robust to extensions "consuming" abstract methods like
Parcelable.describeContents()
. Right now, we get a crash because we see an abstract method likedescribeContents()
but no corresponding setter in the builder./cc @lazaroclapp
The text was updated successfully, but these errors were encountered: