[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
#!/usr/bin/env python
|
|
|
|
# A tool to parse creates a document outlining how clang formatted the
|
|
|
|
# LLVM project is.
|
|
|
|
|
|
|
|
import sys
|
|
|
|
import os
|
|
|
|
import subprocess
|
|
|
|
from datetime import datetime
|
|
|
|
|
|
|
|
|
|
|
|
def get_git_revision_short_hash():
|
2021-10-03 19:08:24 +08:00
|
|
|
""" Get the get SHA in short hash form. """
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
return subprocess.check_output(['git', 'rev-parse', '--short', 'HEAD']
|
|
|
|
).decode(sys.stdout.encoding).strip()
|
|
|
|
|
|
|
|
|
|
|
|
def get_style(count, passed):
|
2021-10-03 19:08:24 +08:00
|
|
|
""" Determine if this directory is good based on the number of clean
|
|
|
|
files vs the number of files in total. """
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
if passed == count:
|
|
|
|
return ":good:"
|
2021-10-03 19:08:24 +08:00
|
|
|
if passed != 0:
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
return ":part:"
|
2021-10-03 19:08:24 +08:00
|
|
|
return ":none:"
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
TOP_DIR = os.path.join(os.path.dirname(__file__), '../../..')
|
|
|
|
CLANG_DIR = os.path.join(os.path.dirname(__file__), '../..')
|
|
|
|
DOC_FILE = os.path.join(CLANG_DIR, 'docs/ClangFormattedStatus.rst')
|
2021-10-03 19:08:24 +08:00
|
|
|
CLEAN_FILE = os.path.join(CLANG_DIR, 'docs/tools/clang-formatted-files.txt')
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
|
|
|
|
rootdir = TOP_DIR
|
|
|
|
|
|
|
|
skipped_dirs = [".git", "test"]
|
|
|
|
suffixes = (".cpp", ".h")
|
|
|
|
|
2021-10-03 19:08:24 +08:00
|
|
|
RST_PREFIX = """\
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
.. raw:: html
|
|
|
|
|
|
|
|
<style type="text/css">
|
|
|
|
.total {{ font-weight: bold; }}
|
2021-10-10 02:34:30 +08:00
|
|
|
.none {{ background-color: #FFFF99; height: 20px; display: inline-block; width: 120px; text-align: center; border-radius: 5px; color: #000000; font-family="Verdana,Geneva,DejaVu Sans,sans-serif" }}
|
|
|
|
.part {{ background-color: #FFCC99; height: 20px; display: inline-block; width: 120px; text-align: center; border-radius: 5px; color: #000000; font-family="Verdana,Geneva,DejaVu Sans,sans-serif" }}
|
|
|
|
.good {{ background-color: #2CCCFF; height: 20px; display: inline-block; width: 120px; text-align: center; border-radius: 5px; color: #000000; font-family="Verdana,Geneva,DejaVu Sans,sans-serif" }}
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
</style>
|
|
|
|
|
|
|
|
.. role:: none
|
|
|
|
.. role:: part
|
|
|
|
.. role:: good
|
|
|
|
.. role:: total
|
|
|
|
|
|
|
|
======================
|
|
|
|
Clang Formatted Status
|
|
|
|
======================
|
|
|
|
|
|
|
|
:doc:`ClangFormattedStatus` describes the state of LLVM source
|
|
|
|
tree in terms of conformance to :doc:`ClangFormat` as of: {today} (`{sha} <https://github.com/llvm/llvm-project/commit/{sha}>`_).
|
|
|
|
|
|
|
|
|
|
|
|
.. list-table:: LLVM Clang-Format Status
|
|
|
|
:widths: 50 25 25 25 25
|
|
|
|
:header-rows: 1\n
|
|
|
|
* - Directory
|
|
|
|
- Total Files
|
|
|
|
- Formatted Files
|
|
|
|
- Unformatted Files
|
|
|
|
- % Complete
|
|
|
|
"""
|
|
|
|
|
2021-10-03 19:08:24 +08:00
|
|
|
TABLE_ROW = """\
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
* - {path}
|
|
|
|
- {style}`{count}`
|
|
|
|
- {style}`{passes}`
|
|
|
|
- {style}`{fails}`
|
|
|
|
- {style2}`{percent}%`
|
|
|
|
"""
|
|
|
|
|
2020-06-28 16:49:39 +08:00
|
|
|
FNULL = open(os.devnull, 'w')
|
|
|
|
|
2021-10-03 19:08:24 +08:00
|
|
|
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
with open(DOC_FILE, 'wb') as output:
|
2021-10-03 19:08:24 +08:00
|
|
|
cleanfiles = open(CLEAN_FILE, "wb")
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
sha = get_git_revision_short_hash()
|
|
|
|
today = datetime.now().strftime("%B %d, %Y %H:%M:%S")
|
2021-10-03 19:08:24 +08:00
|
|
|
output.write(bytes(RST_PREFIX.format(today=today,
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
sha=sha).encode("utf-8")))
|
|
|
|
|
|
|
|
total_files_count = 0
|
|
|
|
total_files_pass = 0
|
|
|
|
total_files_fail = 0
|
|
|
|
for root, subdirs, files in os.walk(rootdir):
|
|
|
|
for subdir in subdirs:
|
|
|
|
if any(sd == subdir for sd in skipped_dirs):
|
|
|
|
subdirs.remove(subdir)
|
2020-06-28 16:49:39 +08:00
|
|
|
else:
|
|
|
|
act_sub_dir = os.path.join(root, subdir)
|
|
|
|
# Check the git index to see if the directory contains tracked
|
|
|
|
# files. Reditect the output to a null descriptor as we aren't
|
|
|
|
# interested in it, just the return code.
|
|
|
|
git_check = subprocess.Popen(
|
|
|
|
["git", "ls-files", "--error-unmatch", act_sub_dir],
|
|
|
|
stdout=FNULL,
|
|
|
|
stderr=FNULL)
|
|
|
|
if git_check.wait() != 0:
|
|
|
|
print("Skipping directory: ", act_sub_dir)
|
|
|
|
subdirs.remove(subdir)
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
|
|
|
|
path = os.path.relpath(root, TOP_DIR)
|
|
|
|
path = path.replace('\\', '/')
|
|
|
|
|
|
|
|
file_count = 0
|
|
|
|
file_pass = 0
|
|
|
|
file_fail = 0
|
|
|
|
for filename in files:
|
|
|
|
file_path = os.path.join(root, filename)
|
|
|
|
ext = os.path.splitext(file_path)[-1].lower()
|
|
|
|
if not ext.endswith(suffixes):
|
|
|
|
continue
|
|
|
|
|
|
|
|
file_count += 1
|
|
|
|
|
|
|
|
args = ["clang-format", "-n", file_path]
|
|
|
|
cmd = subprocess.Popen(args, stderr=subprocess.PIPE)
|
|
|
|
stdout, err = cmd.communicate()
|
|
|
|
|
|
|
|
relpath = os.path.relpath(file_path, TOP_DIR)
|
|
|
|
relpath = relpath.replace('\\', '/')
|
|
|
|
if err.decode(sys.stdout.encoding).find(': warning:') > 0:
|
|
|
|
print(relpath, ":", "FAIL")
|
|
|
|
file_fail += 1
|
|
|
|
else:
|
|
|
|
print(relpath, ":", "PASS")
|
|
|
|
file_pass += 1
|
2021-10-03 19:08:24 +08:00
|
|
|
cleanfiles.write(bytes(relpath + "\n"))
|
|
|
|
cleanfiles.flush()
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
|
|
|
|
total_files_count += file_count
|
|
|
|
total_files_pass += file_pass
|
|
|
|
total_files_fail += file_fail
|
|
|
|
|
|
|
|
if file_count > 0:
|
|
|
|
percent = (int(100.0 * (float(file_pass)/float(file_count))))
|
|
|
|
style = get_style(file_count, file_pass)
|
2021-10-03 19:08:24 +08:00
|
|
|
output.write(bytes(TABLE_ROW.format(path=path,
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
count=file_count,
|
|
|
|
passes=file_pass,
|
|
|
|
fails=file_fail,
|
|
|
|
percent=str(percent), style="",
|
|
|
|
style2=style).encode("utf-8")))
|
|
|
|
output.flush()
|
|
|
|
|
|
|
|
print("----\n")
|
|
|
|
print(path, file_count, file_pass, file_fail, percent)
|
|
|
|
print("----\n")
|
|
|
|
|
|
|
|
total_percent = (float(total_files_pass)/float(total_files_count))
|
|
|
|
percent_str = str(int(100.0 * total_percent))
|
2021-10-03 19:08:24 +08:00
|
|
|
output.write(bytes(TABLE_ROW.format(path="Total",
|
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
|
|
|
count=total_files_count,
|
|
|
|
passes=total_files_pass,
|
|
|
|
fails=total_files_fail,
|
|
|
|
percent=percent_str, style=":total:",
|
|
|
|
style2=":total:").encode("utf-8")))
|