[SmartHolder] fix(clang-tidy): apply clang-tidy performance fixes

[Skylion007]

Description

• This mirrors the clang-tidy performance fixes from master to the smart-holder branch.

Suggested changelog entry:

* Apply various micro-optimizations from clang-tidy

[rwgk]

Just so you're not surprised: the failing Centos 8 build is disabled on this branch.

[rwgk]

aargh - a flake (CI-SH-DEF / 🐍 3 • CentOS7 / PGI 20.9 • x64)

Please ignore, or when it's done you can go to Actions and just rerun the CI-SH-DEF workflow.

Sadly we cannot rerun just one job.

[Skylion007]

Hmm, can't figure out how to rerun. Are the rest flakes?

[rwgk]

Hmm, can't figure out how to rerun. Are the rest flakes?

Yes, the macos failure is because there was no machine available to run the job :-(
Jobs get queued but apparently there's a timeout.
I'll try to find the button to rerun.

[rwgk]

I initiated the Google-internal global testing for this PR. Results will be available tomorrow morning (Pacific timezone).

I ran interactive tests with ASAN and MSAN, covering unit tests in a couple other libraries using pybind11: no issues.

[rwgk]

Good news: The global testing was successful, no issues at all!

I'm strongly in favor of merging on master and here in tandem, as soon as possible. @henryiii, what do you think?

A couple things I'm confused about:

1. When do we need the version bump here (Henry's pointer):

   pybind11/.github/workflows/format.yml

   Line 30 in b4b67f0

   container: silkeh/clang:10

2. Do we have to do anything else to have the checks runs automatically in the GitHub Actions?

[Skylion007]

So it's a little more complicated than I initially though. Disabling the checks in the tests folder works, but since there are no targets with performance checks left after that, clang-tidy won't run any performacne checks against the header files (the header files exist as part of the compilation chain from the test folder). I can't easily filter out all the warnings in the tests folder either while leaving them enabled in the include folder.

Turning this check on probably warrants its own PR. We will need to enable performance checks in the test folder and then manually nolint all the test cases where we want explicit, but unnecessary copies/moves/etc so that clang-tidy is happy.

As such, neither of these PR enables the performance checks to run automatically.

(I currently generate these fixes by apply fixes to the whole repo and then resetting everything outside of include).

[rwgk]

As such, neither of these PR enables it manually.

Thanks for the explanation! Just to verify for myself that I understand correctly, is the following true?

• You simply ignored the clang-tidy complaints under tests/ ?
• clang-tidy regressions in the header files are possible until we have the automatic process in place ?
• But this pair of PRs is a great start ?

(I'm totally fine with all of this, if correct.)

[Skylion007]

Yeah, here let me edit the config to

As such, neither of these PR enables it manually.

Thanks for the explanation! Just to verify for myself that I understand correctly, is the following true?

* You simply ignored the clang-tidy complaints under tests/ ?

* clang-tidy regressions in the header files are possible until we have the automatic process in place ?

* But this pair of PRs is a great start ?

(I'm totally fine with all of this, if correct.)

Exactly. Also, I just realized the automated fixes didn't fix everything. It didn't fix the 'PYBIND11_ENUM_OP*' macros which copies in the objects there. I can add those fixes by hand to this PR, but I don't want to make you have to rerun it on the Google Wide codebase for performance fix that doesn't seem that consequential.

[rwgk]

Exactly. Also, I just realized the automated fixes didn't fix everything. It didn't fix the 'PYBIND11_ENUM_OP*' macros which copies in the objects there. I can add those fixes by hand to this PR, but I don't want to make you have to rerun it on the Google Wide codebase for performance fix that doesn't seem that consequential.

Awesome, thanks! Please feel free adding more to this PR. I will have to rerun the testing anyway after the changes are merged here, so that I have less to explain for the internal reviewers.

BUT another thing: you probably noticed that we don't have a great track record with fast decision making on the master branch. I'm not sure how soon another maintainer will be able to approve the merge there, but I'm pretty actively working on the smart_holder code and prefer to merge your smart_holder-specific fixes basically straightaway, to avoid a mess of conflicts. I looked through the changes pretty carefully and it looks like the fixes for master are nicely separated from the smart_holder-specific fixes, along file boundaries (I was worried about cast.h and pybind11.h, but the smart_holder code in there seems to be unaffected). Is that also your observation? Basically, the smart_holder-specfic changes are in only two files:

• include/pybind11/detail/smart_holder_type_casters.h
• include/pybind11/trampoline_self_life_support.h

Would it make sense to also merge the .clang-tidy change, to have it active on the smart_holder branch ahead of master (I'm still not sure what the change does)?

How about reverting all but these 2 or 3 files here, I'll merge it straightaway, then you only have to worry about the master branch, while I'm pretty sure now that there aren't any complicated merge conflicts in the making.

[Skylion007]

@rwgk Done

[Skylion007]

For reference, all the .clang-tidy change does is remove a false positive from one of the checks.

[rwgk]

Thanks Aaron!