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

Demo clang format 20200206 #1710

Closed

Conversation

Labels
None yet
Projects
None yet
3 participants
@nmathewson
Copy link
Contributor

@nmathewson nmathewson commented Feb 7, 2020

No description provided.

nmathewson added 25 commits Feb 6, 2020
This code transformer makes a couple of changes that we want for our
source code, and can be expanded to handle more.
The format is the same as in my previous efforts here.

The script is a little tricky, since it invokes both clang-format
and codetool, and it makes sure that files do not have a changed
mtime unless there is actually some change in the file.
Clang-format wants to put these in, and they do make sense for
consistency.

Also allow more types.
(The original idiom here led clang-format to generating a too-wide line.)
When we use macro inline, clang-format likes to break it in the
middle, which makes checkSpace get confused.
Clang-format wants to split these messages across multiple lines,
which confuses the heck out of coccinelle.
We want our code to require semicolons after use of these macros,
so that our code formatters and/or analysis tools don't get
confused.
These belong in util_bug.h (and they already are there).

Their presence made clang-format misindent these functions in a way
that checkSpace.pl dislikes.
Doing this makes our macro usage a little clear IMO, and also avoids
having to use an unadorned "new" within a macro.  (Clang-format
seems to think that "new" means we're doing C++, and so it generates
some output that checkSpace.pl doesn't care for.)
clang-format sometimes thinks that "#name" should be written as
"#     name" if it appears at the start of a line.  Using () appears
to suppress this, while confusing Coccinelle.
These tables have aligned comments, so we don't want clang-format to
mess with them.
Previously we would forbid macro indentations like this:

FOO({
  int x;
  })

But clang-format sometimes generates those.
clang-format wants to put no space here, so we need to tell the test
to expect a lack of a space.
These are not a problem with 2-space indentation, but cocci will
start getting confused when clang-format wraps them with 4-space
indentation.
We're telling clang-format that a line with LCOV_EXCL must not be
split -- that's fine, but we shouldn't complain when it indents it.
@coveralls
Copy link

@coveralls coveralls commented Feb 7, 2020

Pull Request Test Coverage Report for Build 7990

  • 9001 of 15735 (57.2%) changed or added relevant lines in 288 files are covered.
  • 669 unchanged lines in 114 files lost coverage.
  • Overall coverage decreased (-0.1%) to 63.232%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/core/crypto/onion_tap.c 23 24 95.83%
src/core/or/channelpadding.c 36 37 97.3%
src/core/or/circuitmux_ewma.c 27 28 96.43%
src/core/or/protover.c 64 65 98.46%
src/feature/control/btrack_orconn_maps.c 6 7 85.71%
src/feature/dirauth/dirauth_config.c 10 11 90.91%
src/feature/dircommon/fp_pair.c 15 16 93.75%
src/feature/hs/hs_circuitmap.c 16 17 94.12%
src/feature/hs/hs_dos.c 9 10 90.0%
src/feature/hs/hs_ident.c 0 1 0.0%
Files with Coverage Reduction New Missed Lines %
src/core/crypto/onion_crypto.c 1 5.71%
src/core/mainloop/connection.h 1 42.86%
src/core/mainloop/cpuworker.c 1 0%
src/core/mainloop/periodic.c 1 59.29%
src/core/or/channelpadding.c 1 97.83%
src/core/or/scheduler_vanilla.c 1 75.0%
src/core/or/versions.c 1 93.97%
src/feature/api/tor_api.c 1 50.0%
src/feature/client/entrynodes.c 1 86.39%
src/feature/control/control_bootstrap.c 1 47.47%
Totals Coverage Status
Change from base Build 7980: -0.1%
Covered Lines: 49932
Relevant Lines: 78966

💛 - Coveralls

@torproject-pusher torproject-pusher deleted the branch torproject:master May 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment