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
I'm using JavaExpression to represent simple expressions. I've noticed BinaryOperations get assigned the wrong return type for comparison operators.
For example, evaluating the expression StringToJavaExpression.atPath("6 > 5", getCurrentPath(), checker).getType() in a BaseTypeVisitor yields a primitive TypeMirror for int, when it should be boolean. The same is true for other comparison operators: <, <=, >=, ==, !=. All of them supposedly produce an int instead of a boolean. It's analogous for comparisons involving other primitive types.
I'm running this with JDK 21, Checker Framework version 3.48.3.
I believe I've identified the issue to be located here. The handling for binary expressions falsely assumes that the return type of the expression is always directly related to the type of the operands.
The text was updated successfully, but these errors were encountered:
Thanks for the report and especially for the pull request. (And our apologies for the bug.)
No need for any apologies, thanks for getting back to me so quickly. I'll get to the PR soon. I hope you've had/you're having a relaxing holiday season 🙂
I'm using
JavaExpression
to represent simple expressions. I've noticedBinaryOperation
s get assigned the wrong return type for comparison operators.For example, evaluating the expression
StringToJavaExpression.atPath("6 > 5", getCurrentPath(), checker).getType()
in aBaseTypeVisitor
yields a primitiveTypeMirror
forint
, when it should beboolean
. The same is true for other comparison operators:<
,<=
,>=
,==
,!=
. All of them supposedly produce anint
instead of aboolean
. It's analogous for comparisons involving other primitive types.I'm running this with JDK 21, Checker Framework version 3.48.3.
I believe I've identified the issue to be located here. The handling for binary expressions falsely assumes that the return type of the expression is always directly related to the type of the operands.
The text was updated successfully, but these errors were encountered: