Skip to content
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

Update Static Analysis #1350

Merged
merged 7 commits into from
Aug 21, 2020
Merged

Conversation

RussellSpitzer
Copy link
Member

@RussellSpitzer RussellSpitzer commented Aug 17, 2020

This is an incomplete upgrade but enough to compile the new code and expose the new warnings.

Version Bumps
baseline 0.55 -> 3.36.2
git-version 0.9 -> 0.12.3

Checkstyle Changes Require for Compile

  • LineLength no longer is a Treewalker so it needs to be moved
  • MissingJavaDocMethod is now it's own module, allowMissingThrows properties have been removed
  • MinLineCount was owned by MissingJavaDocMethod but we only set this to a huge number

FindBug Suppression Required for Compile

  • StrictUnusedVariables must be disabled because we have several hundred cases of method parameters not being used in their bodies

New Checkstyle Violations

  • RightCurly - We use Same but this triggers on private constructors with same line braces

New Baseline/Findbug Warnings

  • Final Class - Class not declared final but all constructors are private
  • Javadoc Missing Summary - No Summary mostly in our case this is where we have methods with only a @return
  • RawTypes - Using a parameterized class without a parameterized type
  • ReferenceEquality - We have a few instances of == instead of Equals
  • LambdaMethodReference - Using s -> s.foo instead of s::foo
  • LoggerEnclosingClass - using getLogger for super in child
  • UncessaryAnonymousClass - Extend Function instead of using a lambda
  • CollectionUndefinedEquality - Using equality or contains on Collection without it's own equals or badly behaving equality like (UTF8 strings)
  • JDKObsolete : Collection of many things
    • Using Date (we use Date internally in some places we don't need to be using it)
    • Using linked list ( Warning argues that it is not performed compared to ArrayList and we should us that unless we need nulls or want to benchmark)
    • SortedMap is deprecated use NavigableMap instead
  • Public constructor for Abstract Class
  • CollectionStreamForeach : Collection.stream.foreach should be Collection.foreach
  • MissingOverrides

@RussellSpitzer
Copy link
Member Author

RussellSpitzer commented Aug 20, 2020

So the Issue with Right Curly is that in previous versions of check style it was broken.
checkstyle/checkstyle#6345

We use these directive

        <module name="RightCurly"> <!-- Java Style Guide: Nonempty blocks: K & R style -->
            <property name="option" value="alone"/>
            <property name="tokens" value="CLASS_DEF, METHOD_DEF, CTOR_DEF, LITERAL_FOR, LITERAL_WHILE, STATIC_INIT, INSTANCE_INIT"/>
        </module>

On Constructors, which means every usage of private Constructor(){} is illegal. It just wasn't marked previously.

Since we have decided that this is ok (It's present in dozens of files) I'm going to remove the "CTOR_DEF" check

We have a few other instances of methods failing to place their new } on a new line, but only about 4. So I'm going to fix those.

Remove check for Constructors on a single line, We do this alot
Fix several methods without braces on their own lines
Fix incorrect indentation in a few files
@RussellSpitzer
Copy link
Member Author

@kbendick I know you were interested in this, you can see from this build a large number of new warnings :) Some I think we can just turn off but I suggest that for this PR we probably just leave warnings as is and fix the warnings in subsequent PR's.

cc: @aokolnychyi + @rdblue

OrElse vs OrElseGet
this.localityPreferred = options.get("locality").map(Boolean::parseBoolean)
.orElse(LOCALITY_WHITELIST_FS.contains(scheme));
.orElse(localityFallback);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because schema is non-final we can't just switch this to a lambda

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think actually this would actually be fine, but to make the rules happy we would have to reassign Scheme anyway so I figured we may as well just put the result in a local var

Copy link
Contributor

@rdblue rdblue Aug 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could refactor scheme detection into a method to make scheme effectively final here.

<property name="allowedAnnotations" value="Override, Test"/>
<property name="allowThrowsTagsForSubclasses" value="true"/>
<property name="validateThrows" value="false"/>
Copy link
Contributor

@rdblue rdblue Aug 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems more general than "allowThrowsTagsForSubclasses"? Are we sure it does the same thing?

Copy link
Member Author

@RussellSpitzer RussellSpitzer Aug 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit of a complicated story

checkstyle/checkstyle#7329

Long story short, the checks were basically broken in check style so they were removed and are no longer valid configs. We actually don't need to set "validateThrows" to false either since it is false by default. I just wanted to make sure we were aware that we weren't validating any throw related tags.

@@ -347,7 +347,9 @@ public String toString() {
}

@Override
public void setBatchSize(int batchSize) {}
public void setBatchSize(int batchSize) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we require the empty line?

Copy link
Member Author

@RussellSpitzer RussellSpitzer Aug 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, we actually did for the Private Constructors as well but we were ignoring that everywhere so I deleted that check

        <module name="RightCurly"> <!-- Java Style Guide: Nonempty blocks: K & R style -->
            <property name="option" value="alone"/>
            <property name="tokens" value="CLASS_DEF, **METHOD_DEF**, CTOR_DEF, LITERAL_FOR, LITERAL_WHILE, STATIC_INIT, INSTANCE_INIT"/>
        </module>

Basically Check-style was just broken before (see my comment on this PR) and didn't work correctly on empty blocks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't suppose it's possible to make it okay to have the right curly on the line just after the method definition?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is allowed, I'll change it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that allow us to turn it back on for private constructors without too much trouble?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You want to have it on for private constructors and I can change all the references to

private Constructor() {
}

Because I can do that no problem

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's what we do in most places isn't it? I was hoping that with this update it wouldn't be too many places to change. Probably good to update them to all be standard, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we can do that in a separate PR if you want to keep this one small.

@@ -267,7 +267,7 @@ private static TypeDescription buildOrcProjection(Integer fieldId, Type type, bo
// e.g. renaming column c -> d and adding new column d
String name = Optional.ofNullable(mapping.get(nestedField.fieldId()))
.map(OrcField::name)
.orElse(nestedField.name() + "_r" + nestedField.fieldId());
.orElseGet(() -> nestedField.name() + "_r" + nestedField.fieldId());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice that it catches these.

@rdblue
Copy link
Contributor

rdblue commented Aug 20, 2020

Overall, looks good to me.

@rdblue
Copy link
Contributor

rdblue commented Aug 21, 2020

Is this still WIP? It looks about ready to me. We can always follow up with more.

We decided to enforce no single line constructors
Use todoComment rules as a CommentRegex to find comments which lead
with a word character. Flags these instances as a mistake.
@RussellSpitzer
Copy link
Member Author

Updated even more rules,
No more single line constructors
Comments must not lead with a "word" character

@RussellSpitzer RussellSpitzer changed the title Update Static Analysis WIP Update Static Analysis Aug 21, 2020
@rdblue rdblue merged commit 44c1d00 into apache:master Aug 21, 2020
@rdblue
Copy link
Contributor

rdblue commented Aug 21, 2020

Thanks for fixing this, @RussellSpitzer! Really good to have checks working automatically.

@RussellSpitzer RussellSpitzer deleted the UpdateStaticAnalysis branch August 21, 2020 20:20
@RussellSpitzer
Copy link
Member Author

Thanks for reviewing!

@rdblue rdblue linked an issue Aug 21, 2020 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Checkstyle Improvements
2 participants