Skip to content

Fix the compiler warnings in hand-written code - #84

Open
jtnelson wants to merge 3 commits into
developfrom
feature/fix-compiler-warnings
Open

jtnelson wants to merge 3 commits into
developfrom
feature/fix-compiler-warnings

Conversation

@jtnelson

Copy link
Copy Markdown
Member

Summary

javac -Xlint:all reported 20 warnings in ccl's hand-written sources. This change removes the cause of each warning that has one, and suppresses the one that a signature requires.

Behavior

  • The deprecated constructor Expression(TimestampSymbol, KeySymbol, OperatorSymbol, ValueSymbol...) carries @Deprecated, as its Javadoc already stated, so code that calls it now gets a compiler deprecation warning.
  • ASTExpression suppresses unchecked warnings at the class level. Its key() returns KeyTokenSymbol<?> for the generic key() of ExpressionSymbol, and javac checks that conversion at the class, so a suppression on the method has no effect.
  • CompilerJavaCCLogicTest and JavaCCParserLogicTest assert the same values without casting KeyRecordsFunction#source() to the List<Long> it already returns.

javac -Xlint:all reported 20 warnings in the hand-written sources. Two
parser test classes cast KeyRecordsFunction#source() to the List<Long> it
already returns. The deprecated Expression constructor that takes a
timestamp had @deprecated in its Javadoc but no @deprecated annotation, so
its callers got no compiler warning. ASTExpression#key() returns
KeyTokenSymbol<?> for the generic key() of ExpressionSymbol; javac checks
that conversion at the class, so the method's own
@SuppressWarnings("unchecked") had no effect.

The casts are gone, the constructor carries @deprecated, and ASTExpression
suppresses unchecked warnings at the class level.
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

Successfully merging this pull request may close these issues.

1 participant