@carlosgalvezp Thanks for your review! I committed it myself.

Rebased.

Hi, Could anyone please review this diff?

Friendly ping.

Friendly ping.

Mark comments.

Improved the test file.

Added comments

Friendly ping.

Friendly ping.

Added test in existing init-variables.cpp file.

Added test.

This patch has been around for a long time, I have added the release notes. There are users waiting for this fix and I committed it myself first.
@LegalizeAdulthood I'm looking forward to your follow-up reply.

Rebased.

Friendly ping @LegalizeAdulthood.

Hi, @LegalizeAdulthood, are you okay with the way this has progressed?

Rebased.

Friendly ping.

Friendly ping.

Added test cases where there is a struct with an anonymous union and another field that does need an initializer.

Friendly ping.

Friendly ping.

Friendly ping.

In D128697#3619310, @LegalizeAdulthood wrote:

This whole check seems weird to me. I mean, almost every use of a standard container could throw std::bad_alloc but we don't insist on a local catch for bad_alloc at every possible throwing call site.

Why would we assume that every call site of stoi or stod must have an exception handler immediately around it? It's perfectly acceptable for an application to handle this at an outer scope that can't be detected by clang-tidy.

In D128697#3615404, @Eugene.Zelenko wrote:

I think will be good idea to make check more generic and allow user-defined list of unsafe functions.

Added release notes.

rebased.

rebased.

Fix test file.

rebased.

Rebased and added '-fno-delayed-template-parsing' option for the test file.

I'm not quite sure why the test case is not passing on Windows, could you please check this problem? Thanks for your assistance. @flx

Hi, Could anyone please review this diff?

rebased.

Friendly ping.

Friendly ping.

Rename the function.

It stands to reason that there should be no insert conflicts in the YAML generated by clang-tidy except for the header insertion. The two checks that caused the conflict should be fixed in clang-tidy.

Added an option to ignore insert conflict and this option was enabled by default in run-clang-tidy.py.

Added a release note.

Added a release note.

Removed the fix for the virtual function.

Removed the fix for the template.

rebased.

Add a release note and improve test description information.

In D107450#3257877, @aaron.ballman wrote:

Do you need someone to commit on your behalf?

Improve some description.

Thanks for improving this check! I think it looks great and safe enough. It would be better to turn !(*ptr).empty() into !ptr->empty(), but I have no particular opinions at this point. Let's see if @aaron.ballman has any comments.

Friendly ping.

Friendly ping. @aaron.ballman

Friendly ping. @aaron.ballman

Add some checks for null and comments for codes.

Thanks for your review!

Sorry for the late reply. I made improvements to the patch in response to the questions you raised. @aaron.ballman

Could you please add a test case where the smart pointer object is dereferenced before calling size()? E.g. return (*ptr).size() == 0;. I think this change doesn't work on this test case.

Kindly ping. @aaron.ballman

In D107450#3155019, @whisperity wrote:

This generally looks fine for me, but I'd rather have other people who are more knowledgeable about the standard's intricacies looked at it too.

AFAIK Aaron is busy this week and the next (?) due to C++ Committee meetings, or something like that. And I bet after such meetings everyone would take a few more days off from looking at C++ stuff.

Hi, Could anyone please review this diff? @whisperity, @aaron.ballman

Kindly ping. @whisperity

Kindly ping. @whisperity

In D113148#3108705, @CJ-Johnson wrote:

In D113148#3107897, @Sockke wrote:

This seems to be an existing check. Have you compared it with bugprone-string-constructor?

Thanks for the suggestion! From what I can tell, bugprone-string-constructor check only has warnings and does not provide fixes in most cases. The goal of bugprone-stringview-nullptr is to robustly enumerate the many cases that it cares about and provide fixes. For that reason, I think making it a separate check is best.

In addition, the splicing logics of "FunctionName" and "ExpectParmTypeName" were improved.

I improved the logic of judgments needing to report suggesting notes in some cases. And more tests were added here.

This seems to be an existing check. Have you compared it with bugprone-string-constructor?

In D107450#3087103, @whisperity wrote:

I think this is becoming okay and looks safe enough. I can't really grasp what HasCheckedMoveSet means, and how it synergises with storing CallExprs so maybe a better name should be added. Do you mean AlreadyCheckedMoves? When is it possible that the same CallExpr of std::move will be matched multiple times?