-
Notifications
You must be signed in to change notification settings - Fork 28.2k
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
[SPARK-3873] [build] Add style checker to enforce import ordering. #6502
Conversation
This is the same code I sent out a long time ago, updated to also hook up to the maven build. I tried both sbt and maven. There is a huge number of warnings, so I won't even try to fix them (in this change or a separate one), but since there seems to be a push to add more style checks, thought I might send this out again. |
Test build #33752 has finished for PR 6502 at commit
|
Will this even pass tests in its current state? I imagine we violate the import ordering in a lot of places currently. |
@andrewor14 he's doing warning level checks right now -- so there will be lots of warnings but still pass. Let's see how many warnings there are ... |
I see... retest this please? |
Test build #33764 has finished for PR 6502 at commit
|
Test build #33771 has finished for PR 6502 at commit
|
The PR builder script redirects the scalastyle output to a file and deletes it... so you don't see the warnings in the output and can't find them on the jenkins machines either. But you'll see them if you try this change locally. |
What happens to errors? Are they also redacted? |
See |
@vanzin - thanks, this looks great. Can you do 3 things?
The reason is we should avoid one-offs that make it harder to upgrade in the future (e.g. scalastyle sometimes change their internals, and then we'd need to learn how to upgrade this rule when we upgrade scalastyle). We can merge this as soon as there is a pull request against scalastyle and way to move forward. And once that is merged into scalastyle and scalastyle releases a new version, we can remove our one-off rule. This is what we have done for all the one-off rules in the past. |
By the way, if you make this configurable then I'd model the configuration language / format after IntelliJ's import ordering configuration dialog. |
I filed a scalastyle PR (see link above) which contains tests, so I'll avoid adding those tests to this PR. |
Test build #33932 has finished for PR 6502 at commit
|
Test build #35797 has finished for PR 6502 at commit
|
LFTM. @rxin? |
@vanzin, it looks like the Scalastyle PR was merged: scalastyle/scalastyle#147 Given this, can you update this PR to configure Scalastyle to use this new rule? |
It was merged but I don't see a new scalastyle release. I was waiting for that before updating this pr. |
Can you comment on scalastyle/scalastyle#157 to voice your support for a new Scalastyle release? The delays in getting new Scalastyle and Scalastyle-SBT versions published are causing a lot of pain for folks running Scala 2.10.5+, since the current master also contains bugfixes for a Scalariform parser issue. |
Err, sorry, the link above should have been scalastyle/scalastyle#157 |
Still no Scalastyle release :( I tried bumping that ticket again. |
Now that Scalastyle 0.8.0 has been released, I think we can revive this PR. I've opened #10112 to bump the SBT and Scalastyle versions. |
I'm looking into it. |
Currently generates only warnings, since there are many violations. dev/scalastyle was modified to not get rid of the output file, since that contains the list of warnigs which could help with cleaning things up.
I don't expect the tests to pass; there were style errors (unrelated to import ordering) when I tried things locally. |
Test build #47108 has finished for PR 6502 at commit
|
Test build #47149 has finished for PR 6502 at commit
|
Test build #47150 has finished for PR 6502 at commit
|
Test build #47274 has finished for PR 6502 at commit
|
not that it should matter, but retest this please |
Test build #47355 has finished for PR 6502 at commit
|
I'm gonna merge this so we can start cleaning things up before enabling errors. |
The checker tries to follow as closely as possible the guidelines of
the code style document, and makes some decisions where the guide is
not clear. In particular:
same package
In some projects, such as graphx, there seems to be a convention to
separate o.a.s imports from the project's own; to simplify the
checker, I chose not to allow that, which is a strict interpretation
of the code style guide, even though I think it makes sense.
Since the checks are based on syntax only, some edge cases may
generate spurious warnings; for example, when class names start
with a lower case letter (and are thus treated as a package name
by the checker).
The checker is currently only generating warnings, and since there
are many of those, the build output does get a little noisy. The
idea is to fix the code (and the checker, as needed) little by little
instead of having a huge change that touches everywhere.