@dblaikie thoughts?

> Imaginate that such trivial type could be for example 200KB in size

Trivial types should not be passed by rvalue reference, but by value per the diagram under http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#fcall-parameter-passing. I feel like adding an option to opt-out of this is missing the point of this check, and rvalue references of trivial type should just be fixed rather than adding an option to permit them.

• More matcher simplification

Ok, all feedback should be addressed (thanks for the comment to consolidate into a single matcher) with appropriate options to relax the enforcement of the guideline.

• Include non-deduced template types

• Finish combining into a single matcher
• Rename option and add docs

• Use bool
• Combine into a single matcher

Simplified matchers

• Simplify matcher

• Ignore params of template type
• Add option for unnamed params

I was split on handling the case where the parameter that was never moved from was not named. For this guideline enforcement to flag all unmoved rvalue reference parameters, code that std::moves into an argument to a virtual method call could be especially confusing or dangerous with regards to whether the object was truly "moved" (move constructor/assignment invoked within the method call). E.g.,

• Remove duplicated matchers

• Add back -fno-delayed-template-parsing to test

@PiotrZSL I added an option to allow disabling the strict behavior. It should address many of your examples (e.g., moving subobjects) . Let me know if you have more feedback.

rebase again

Rebased as well on top of the latest release notes

• Add back -fno-delayed-template-parsing to test

• Add StrictMode option, fix const&& bug

@PiotrZSL The last forward example you have should match my does_move_auto_rvalue_ref_param test, which is not flagged by the tool. Let me know if you have any other forward cases (preferred as full self contained examples) that the tool incorrectly flags, as getting forward / universal references cases are important for this tool.

Some of the examples you mentioned are indeed not compliant with guideline F.18. I have a test for at least one of the examples you gave (moves_deref_optional matches your first example). The guideline is fairly strict IMO, and I asked about this in https://github.com/isocpp/CppCoreGuidelines/issues/2026, but the response was that the guideline will remain with the requirement that the whole object needs to be moved. This would imply that the fix for cases like moves_deref_optional would be to change the parameter to be a value rather than rvalue reference of the type (and move the individual parts as desired). Example X&& obj as argument + for(auto& v : obj) { something(std::move(v.x)); } also violates F.18 since the whole object is not moved (just a subobject, although I'm a little confused about the loop also).

poke - anyone mind reviewing this?

• Add more cases to swapped params

• Fix BitVector

• Add test

Realistically, I'm not sure if this change is all that valuable aside from abiding by the CppCoreGuidelines from the readability and consistency standpoint. The only impact this change would have that I can think of is allowing an object with an && (or other combination) qualified operator() that would be picked up by this change, which doesn't seem likely of a use case for this function. I'll try to add a small test that covers this and leave it to the maintainers whether this is a worthy change :)

Another benefit is (and I might have been using the options incorrectly, which furthers the pointd made earlier I think) is that the recursive cmake invocations did not end up forwarding the LLVM_CCACHE_BUILD value, so only the top level build would be using ccache. The *COMPILER_LAUNCHER variable seems to get passed down correctly, although I'm sure if that's explicit or a happy coincidence.

• Add more

Looks good to me - looking forward to this check!

Looks good to me including the cmake logic. I've been building with the launcher environment variables since I posted the Discourse post. I can't really speak to the build bot side, which doesn't look to have been updated based on the most recently build of this diff.

https://reviews.llvm.org/D137205 looks to be similar in part, as it applies a FixIt to a any last use of an object if the use a copy, including parameters and local objects.

• Update per https://github.com/isocpp/CppCoreGuidelines/issues/2026

• Add parameter name to diagnostic

This is more or less ready for review (not planning on making any further changes; there are more features to be added, but I was thinking of handling those in follow up changesets). I know it's a relatively large review, but let me know if anyone can take a first pass. Thanks!

Yes, locally I get

This should do: Chris Cotter <ccotter14@bloomberg.net>

Thanks! I don't have push access, so if you're good with this, could you please land this for me?

Gentle poke for any last reviews?

Rebase + Simplify match logic

In https://github.com/isocpp/CppCoreGuidelines/issues/2026, it looks like the core guideline will not permit exceptions for code that accepts an rvalue ref parameter, and the function body moves members of the parameter. So, my moves_member_of_parameter test case would be flagged. In theory, we could add a tool option to allow someone to live more "dangerously" and have the tool accept code like moves_member_of_parameter, with the caveat that the tool (as I have written it so far) would not be smart enough to detect that all static paths move every data member of the object. In any case, I'll update my test and the tool to align exactly with the guideline.

rebase

rebase

• Use multiple runs on the same test file

In D141569#4048359, @njames93 wrote:

What happens with code like this

void foo(bar&& B) {
  std::move(B);
}

• Use match instead of bespoke traversal

• Fix universal reference check; move diagnostic location to parameter name

Thanks for reviewing and merging my recent changes!

• Use nested namespaces

• Allow move of any expr containing the parameter

• Properly handle forwarding references

• Use nested namespace in header too;

• Use nested namespace

• Add fno-delayed-template-parsing

• Fix windows, fix crash

• Fix windows, fix crash

What happens with code like this

void foo(bar&& B) {
  std::move(B);
}

• cleanup comments, docs

Would someone with merge access mind committing this? I double checked and this diff can be applied on the latest upstream/main. Thanks!

• fix merge

In D141892#4058273, @njames93 wrote:

In D141892#4057722, @ccotter wrote:

2. replace the non _v templates to the _v variants is_same -> is_same_v or the equivalent concept same_as

See D137302

Overall, we could eventually upgrade code in three stages, each a separate reusable check.

For the sake of demonstration, https://github.com/llvm/llvm-project/commit/9c556ce59edf5a4293d4497d5815544afc0eb878 is the result of running this tool on all headers under clang/include/clang and llvm/include/llvm.

• Match unresolved calls to move

• two more tests
• Minimize test

What happens with code like this

void foo(bar&& B) {
  std::move(B);
}