Unify InferredJARModelsHandler and LibraryModelsHandler
#1072
Assignees
Comments
This was referenced Nov 11, 2024
msridhar
added a commit
that referenced
this issue
Dec 12, 2024
In particular, fix cases where the type of a method parameter either contains generic type arguments or is itself a type variable. These fixes are needed for #1072. We take advantage of the fact that even though `javac` erases generics, it stores full generic type signatures in class file attributes, which WALA is able to read. So we can recover generic type information from these attributes. We needed a bug fix from WALA for this to work, hence the WALA version bump. Not every case is supported here (e.g., we haven't tested generic methods). But these changes are enough to enable #1072 to move forward, after which we will have a single place to add features and fix bugs.
msridhar
added a commit
that referenced
this issue
Dec 16, 2024
Now, all logic for parsing loading `astubx` files is consolidated into the `LibraryModelsHandler.ExternalStubxLibraryModels` class and is uniform for `astubx` files generated via JarInfer or from source code, which will ease future bug fixes and changes. We copied over the logic from `InferredJARModelsHandler` for loading Android SDK models if present. We also update the logic for `ExternalStubxLibraryModels.nonNullParameters()` and `ExternalStubxLibraryModels.nullableReturns()` to pull in all the relevant info from the parsed `astubx` file. Fixes #1072
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should have unified code paths for handling library models, whether they are given explicitly or coming from astubx files. Fixing this will require removing inconsistencies in the current handling:
The text was updated successfully, but these errors were encountered: