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

Update handling of varargs in unannotated / unmarked code #1027

Open
msridhar opened this issue Sep 2, 2024 · 0 comments
Open

Update handling of varargs in unannotated / unmarked code #1027

msridhar opened this issue Sep 2, 2024 · 0 comments

Comments

@msridhar
Copy link
Collaborator

msridhar commented Sep 2, 2024

Follow-up to #1025. If the varargs argument is in unannotated code and restrictive annotations are disabled, callers from marked code should be able to pass @Nullable either for individual varargs arguments or a @Nullable varargs array.

With restrictive annotations enabled, hopefully this table should cover the behaviors when we see explicit @NonNull annotations (legacy mode behavior to be confirmed):

Annotation Type Annotation Position Mode @NonNull varargs array @NonNull individual args
declaration - standard
declaration - legacy
declaration - JSpecify
type use before ... standard
type use before ... legacy
type use before ... JSpecify
type use elements standard
type use elements legacy
type use elements JSpecify
type use both standard
type use both legacy
type use both JSpecify
both before ... standard
both before ... legacy
both before ... JSpecify
both elements standard
both elements legacy
both elements JSpecify
both both standard
both both legacy
both both JSpecify

Note that restrictive annotations are read from @NullUnmarked code by default, so calls into @NullUnmarked code should behave as per the table even if the restrictive annotations flag is not passed.

msridhar added a commit that referenced this issue Sep 7, 2024
…d code (#1029)

Partially addresses #1027. Most importantly, handles the case with
unannotated methods and _no_ restrictive annotations; we were getting
warnings in some cases with the main branch, which impacts backward
compatibility.

I started implementing full support for restrictive annotations on
varargs parameters and then realized it would take some refactoring
(since there can be a restrictive annotation on the varargs array itself
or on its contents, and we have no way to express this in the current
code structure). This PR contains some incomplete code towards that
change, which I figured does no harm so I left it in for now. If desired
I can remove it and put it in a separate PR.
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