Skip to content

Conversation

@pietern
Copy link
Contributor

@pietern pietern commented Sep 5, 2019

Stack from ghstack:

This change updates the tools/clang_format.py driver script to exit
with non-zero status on error, fix running with --check-all, use
some of the tricks that have been added to tools/clang_tidy.py over
time, and more.

It also:

  • Removes the jit paths from the whitelist (they are not formatted).
  • Updates the pre-commit hook to deal with the non-zero exit status.
  • Adds tools/run-clang-format-in-ci.sh.
  • Adds an Azure pipeline to run clang-format in CI.

This change updates the `tools/clang_format.py` driver script to exit
with non-zero status on error, fix running with `--check-all`, use
some of the tricks that have been added to `tools/clang_tidy.py` over
time, and more.

It also:
* Removes the jit paths from the whitelist (they are not formatted).
* Updates the pre-commit hook to deal with the non-zero exit status.
* Adds `tools/run-clang-format-in-ci.sh`.
* Adds an Azure pipeline to run clang-format in CI.
@pytorchbot pytorchbot added module: infra Relates to CI infrastructure module: lint Issues related to our Python/C++ lint rules (run by Travis) labels Sep 5, 2019
@pietern
Copy link
Contributor Author

pietern commented Sep 5, 2019

This change updates the `tools/clang_format.py` driver script to exit
with non-zero status on error, fix running with `--check-all`, use
some of the tricks that have been added to `tools/clang_tidy.py` over
time, and more.

It also:
* Removes the jit paths from the whitelist (they are not formatted).
* Updates the pre-commit hook to deal with the non-zero exit status.
* Adds `tools/run-clang-format-in-ci.sh`.
* Adds an Azure pipeline to run clang-format in CI.
@pietern pietern requested review from ezyang, suo and zdevito September 5, 2019 10:40
@ezyang
Copy link
Contributor

ezyang commented Sep 5, 2019

Can we update the wiki with information about how to run clang-format locally? https://github.com/pytorch/pytorch/wiki

# Exits with non-zero status if clang-format generated changes.
time python tools/clang_format.py \
--verbose \
--diff "$BASE_BRANCH" \
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's please run clang-format on all files in CI, not the diff only. Having it be diff-based in clang-tidy means that most of the time there is broken code in master and we don't know about it.

Copy link
Contributor

@ezyang ezyang left a comment

Choose a reason for hiding this comment

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

CI formatter should run on all files. If that means that we have to blacklist some files to start, let's do that.

Copy link
Member

@suo suo left a comment

Choose a reason for hiding this comment

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

The reason we never did this is because different version of clang-format produce different results. Notably the default version on fb devservers is at some random point (not a release). So unless we can figure out a way to get everyone using the same clang-format in their editor, this will cause a lot of noise.

@pietern
Copy link
Contributor Author

pietern commented Sep 5, 2019

@suo Thanks for the insight. I figured it was somehow progressive in nature.

I just checked and fb devservers have 8.0 installed, which is the same as run in the Azure pipeline.

@suo
Copy link
Member

suo commented Sep 5, 2019

The version number that clang-format --version reports may be misleading, since fb does some weird stuff with their tooling versioning I think (this may have changed since I last looked at it though).

But even if devserver and azure is the same, we would need to get external contributors, devfairs, peoples' laptops, etc. to be on the same version. Generally people have been resistant to adding another hoop for OSS people to jump though to contribute to PyTorch (as I'm sure you know).

This is solvable-ish through tooling, for example Chrome stores canonical clang-format binaries for each platform and has a script to download+run the binary on the codebase. We could do the same.

@ezyang
Copy link
Contributor

ezyang commented Sep 5, 2019

Can we just use Chrome's binaries? :)

@suo
Copy link
Member

suo commented Sep 5, 2019

Haha, maybe—although they update once in a while atomically with running the new version on the whole codebase, so that would be annoying.

If we wanted to go that route, I think the work items would be:

  1. Figure out what binary to use. It needs to be the one in fbcode, since otherwise people working fbcode-first will have a tough time. We need to figure out if there's some special rev fbcode tools are based on and compile that rev for platforms we care about.
  2. Get binaries in S3
  3. Write a script that downloads the binaries w/ caching and formats a whitelist (and gitignore the cached binary)
  4. Figure out how to get everyone to run this script (required pre-push hook?), and as a bonus get the right binary in everyone's PATH "somehow"
  5. Activate the CI that checks the whitelist
  6. Expand the whitelist while trying not to run afoul of too many merge conflicts

@ShahriarRezghi
Copy link

@pietern A comment on the checking script. I have used a MIT licensed code in torchvision to check format (link) I think it is more suitable to use in this case. What do you think?

@pietern
Copy link
Contributor Author

pietern commented Sep 9, 2019

@ShahriarSS It looks like that script is also a clang-format runner. What makes it more suitable?

@zdevito zdevito removed their request for review September 10, 2019 20:05
CLANG_FORMAT_WHITELIST = ["torch/csrc/jit/", "test/cpp/jit/"]
CLANG_FORMAT_WHITELIST = [
"torch/csrc/distributed/",
"torch/lib/c10d/",
Copy link
Contributor

Choose a reason for hiding this comment

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

q: is there a way to check which directories are fully compliant (i.e. maybe by running clang-format recursively on them)? If there is, should we do that and add them here?

name_to_diff[filename] = diff

# If no files produced a clang-format diff, exit early.
if len(name_to_diff) == 0:
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this appears to occur when the code is formatted correctly, should we add:
if VERBOSE: print('No formatting changes were found')

to distinguish this from the case where no files were detected? Might help users distinguish between errors caused by passing in files incorrectly versus not having any formatting issues.

@facebook-github-bot
Copy link
Contributor

Hi @pietern!

Thank you for your pull request. We require contributors to sign our Contributor License Agreement, and yours needs attention.

You currently have a record in our system, but we do not have a signature on file.

In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

@pytorchbot
Copy link
Collaborator

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
Stale pull requests will automatically be closed 30 days after being marked Stale

@pytorchbot pytorchbot added Stale and removed Stale labels Apr 12, 2022
@github-actions
Copy link
Contributor

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.

@github-actions github-actions bot added the Stale label Jun 11, 2022
@github-actions github-actions bot closed this Jul 11, 2022
@facebook-github-bot facebook-github-bot deleted the gh/pietern/10/head branch August 10, 2022 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module: infra Relates to CI infrastructure module: lint Issues related to our Python/C++ lint rules (run by Travis) open source Stale triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants