You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
…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.
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):@NonNull
varargs array@NonNull
individual args...
...
...
...
...
...
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.The text was updated successfully, but these errors were encountered: