Rebase over the current master.

Gentle ping)

In D74692#1923191, @Quuxplusone wrote:

I still think this entire patch is misguided; there's no reason to make the note for const std::string s; std::move(s) any longer than the note for int i; std::move(i) or volatile std::string v; std::move(v). People should not be using moved-from objects, period; and those who want to use moved-from objects, should not enable this clang-tidy check.

However, I have no further comments besides philosophical opposition to the whole idea.

Removed top-level consts.

I'm done, Aaron, Quuxplusone, do you have any comments?

In D74692#1911150, @Quuxplusone wrote:

Anyway, I still don't see the point of this patch. It seems like you're just duplicating the work of performance-move-const-arg. People who want to be shown notes about moves-of-const-args should just enable that check instead.

Cosmetic and style fixes.

Any further comments?

Typo fixed.

1. Special handling for captured variables in lambdas,
2. messages texts were changed.

Warning on use after move is still generated. But there's also an additional note

In D74692#1884054, @Quuxplusone wrote:

(I sent this to the mailing list, but I guess it doesn't show up here unless I do it through Phab. Quoting myself—)

I see your point about how users who care should always be passing this check alongside "performance-move-const-arg"; but IMHO it still makes sense for clang-tidy to warn unconditionally about code of the form

x = std::move(y);
use(y);

regardless of the incidental type of y. Sure, it's technically not wrong if y is const... or if y is a primitive type, such as Widget*... or if y is a well-defined library type, such as std::shared_ptr<Widget>... or if y is a library type that works in practice, such as std::list<int>... but regardless of its technical merits, the code is still logically semantically wrong, and I think that's what the clang-tidy check should be trying to diagnose.

In D74692#1879039, @mboehme wrote:

Even if no move actually happens, the code is still wrong

In D57662#1797607, @derek wrote:

@zinovy.nis @alexfh @JonasToth @MyDeveloperDay

I'd be happy to provide a patch.

• Fixed tests.

@alexfh, do you still have any objections?

Why not just use clang-tidy-diff.py? The clang-tidy-diff.py script has a distinct and somewhat self-documenting name and a very specific purpose (find clang-tidy regressions in a patch), while run-clang-tidy.py is more focused on running over larger bodies of code with a purpose of analyzing or cleaning up. Is there any benefit in having all functionality in run-clang-tidy.py?

Gentle ping.

Added a test.

In D59449#1446839, @thakis wrote:

Can we delete clang-tidy-diff.py with this? (Or delete most of its contents and make it forward to this script?)

In D59449#1435032, @alexfh wrote:

How is this functionality different from the clang-tidy-diff.py script with the -j option being added in the other patch?

Any comments?

One more gentle ping.

Gentle ping.

• honest '--export-fixes': multiple yamls are merged into the resulting one.
• minor cosmetic fixes.

• -j is 1 by default;
• fixed minor remarks;

Any comments?

-j and -export-fixes were made mutually exclusive.

I only say this because I think I might have seen it happen when I was running run-clang-tidy.py over a large code base with a fairly aggressive check/fixit, but frankly I was too new to LLVM to know it wasn't something I might have done wrong.

In D57662#1392509, @MyDeveloperDay wrote:

Just a question.. If clang tidy is running with -fix in parallel, what stops each clang-tidy invocation altering a common header at the same time?

Gentle ping.

Fixed minor typos.