-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Java: Deprecate PrimitiveType.getADefaultValue()
#6796
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
lgtm,codescanning | ||
* The predicate `PrimitiveType.getADefaultValue()` has been deprecated for removal in a future version because its behavior is misleading. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -27,13 +27,24 @@ predicate flowStep(Expr decl, Expr init) { | |
decl.(CastExpr).getExpr() = init | ||
} | ||
|
||
predicate isDefaultValueLiteral(Literal l, Type t) { | ||
t instanceof RefType and l instanceof NullLiteral | ||
or | ||
// Checking here for primitive suffices to make sure that literals below are valid default | ||
t instanceof PrimitiveType and | ||
( | ||
l.(BooleanLiteral).getBooleanValue() = false or | ||
l.(CharacterLiteral).getValue() = 0.toUnicode() or | ||
l.(DoubleLiteral).getDoubleValue() = 0 or | ||
l.(FloatingPointLiteral).getFloatValue() = 0 or | ||
l.(IntegerLiteral).getIntValue() = 0 or | ||
l.(LongLiteral).getValue() = "0" | ||
) | ||
} | ||
|
||
predicate excludedInit(Type t, Expr decl) { | ||
exists(Expr init | flowStep(decl, init) | | ||
// The `null` literal for reference types. | ||
t instanceof RefType and init instanceof NullLiteral | ||
or | ||
// The default value for primitive types. | ||
init = t.(PrimitiveType).getADefaultValue() | ||
isDefaultValueLiteral(init, t) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This looks dodgy from a performance point-of-view. Not as much the code change, but rather, this already looked dodgy before the change. So since it probably worked then it's likely that this depends on decent magic, and the changed code will still depend on magic, but since this isn't a certainty, we should verify this before merging (or update the code to not be so full of cartesian products). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm ok with merging if we can verify that the optimiser pushes relevant magic into both predicates to eliminate the CPs. |
||
or | ||
// The expression `-1` for integral types. | ||
t instanceof IntegralType and minusOne(init) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To resolve the cartesian product worry (all reftypes X all nulls), how about just omitting the Type column? This could be just:
Don't flag Expr e if e is (a) null, (b) zero, or (c) of integral type and negative one. Note this actually expands the query slightly to permit
Integer i = 0;
, but considering we already permitInteger i = -1;
then we should probably accept that anyhow.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the latest response. Was this a suggestion for me or directed to aschackmull, or both of us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both. @aschackmull do you think that's a sensible solution?