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
At first glance, this looks straightforward (though it should come with a test). However, note that we change the value of boundType: Previously, it would match the type parameter's bound type (UPPER or UNBOUNDED, as the case may be). But in our commit, it is always UNBOUNDED. This may change behavior of existing code.
One possibility is to track "wildcard-site unboundedness" as a separate bit, used only to trigger our new UNBOUNDED_WILDCARD_UPPER_BOUND, while leaving boundType untouched to preserve existing behavior.
(The only way I found to set this default was to modify the Checker Framework itself. In particular, I wasn't able to employ an approach like I did in jspecify/jspecify-reference-checker@8e46bea#diff-ce82a59b06d0d82bfc6d06835d1b06ac15619bc3a71617d32189d041f02ca9c0R288: IIUC, that code jumps between usages and declarations, so it can't track whether the wildcard itself appears in null-aware or non-null-aware code. Thus, it can't apply different defaults for the two cases.)
The text was updated successfully, but these errors were encountered:
c24904e
At first glance, this looks straightforward (though it should come with a test). However, note that we change the value of
boundType
: Previously, it would match the type parameter's bound type (UPPER
orUNBOUNDED
, as the case may be). But in our commit, it is alwaysUNBOUNDED
. This may change behavior of existing code.One possibility is to track "wildcard-site unboundedness" as a separate bit, used only to trigger our new
UNBOUNDED_WILDCARD_UPPER_BOUND
, while leavingboundType
untouched to preserve existing behavior.Usage: jspecify/jspecify-reference-checker@94bf778#diff-ce82a59b06d0d82bfc6d06835d1b06ac15619bc3a71617d32189d041f02ca9c0R541
(The only way I found to set this default was to modify the Checker Framework itself. In particular, I wasn't able to employ an approach like I did in jspecify/jspecify-reference-checker@8e46bea#diff-ce82a59b06d0d82bfc6d06835d1b06ac15619bc3a71617d32189d041f02ca9c0R288: IIUC, that code jumps between usages and declarations, so it can't track whether the wildcard itself appears in null-aware or non-null-aware code. Thus, it can't apply different defaults for the two cases.)
The text was updated successfully, but these errors were encountered: