-
Notifications
You must be signed in to change notification settings - Fork 308
Prototype implementation of javac plugin to serialize nullness annotations #1225
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
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1225 +/- ##
============================================
+ Coverage 88.36% 88.44% +0.07%
- Complexity 2366 2369 +3
============================================
Files 89 90 +1
Lines 7693 7772 +79
Branches 1540 1552 +12
============================================
+ Hits 6798 6874 +76
- Misses 450 452 +2
- Partials 445 446 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@cpovirk would be interested to get your thoughts on this approach |
That all sounds reasonable to me. I don't want to obligate @cushon or @eamonnmcmanus to get deep into this, but if either of them wants to run screaming into the chapel to object, now would be the time :) |
This is a new approach to serializing the annotations from https://github.com/jspecify/jdk for use with NullAway. The idea is we build that JDK with this plugin, which will dump out all the discovered annotation info into JSON files. Then, we write some code to take all those JSON files and convert them to astubx for NullAway. I went with JSON instead of directly serializing astubx to iterate more quickly. I have tested with jspecify/jdk and confirmed I can inject this plugin into the build and the output JSON files get created. I haven't started on the code to convert the JSON to astubx yet.
Of course there is much left to do, but I wanted to get this initial implementation up for review rather than dropping a huge PR at the end (and also to enable others to help out). We previously thought about getting out the JDK annotations by parsing the source files (and wrote some code to do so), but I think this approach will be more robust, as in the javac plugin we don't need worry about parsing of recent language features and all symbols are just resolved.
Related to #950 (which probably needs to be updated if we go forward with this approach)