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

Handle AutoValue Extensions #110

Open
msridhar opened this issue Nov 15, 2019 · 1 comment
Open

Handle AutoValue Extensions #110

msridhar opened this issue Nov 15, 2019 · 1 comment

Comments

@msridhar
Copy link
Collaborator

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 like describeContents() but no corresponding setter in the builder.

/cc @lazaroclapp

@msridhar
Copy link
Collaborator Author

msridhar commented Nov 18, 2019

More details on why this is hard. AutoValue Extensions can "consume" arbitrary abstract methods of the @AutoValue class, so that AutoValue doesn't generate a concrete implementation of them:

https://github.com/google/auto/blob/389355d065fbe189d8f7a388beeaebeaaf1d13ae/value/src/main/java/com/google/auto/value/extension/AutoValueExtension.java#L383

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.

msridhar added a commit that referenced this issue Nov 19, 2019
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.
msridhar referenced this issue in msridhar/object-construction-checker Nov 19, 2019
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.
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

No branches or pull requests

1 participant