[PATCH] D90392: [clang-tidy] Omit std::make_unique/make_shared for default initialization.

[Chris Kennelly via Phabricator via cfe-commits]

ckennelly added a comment.

In D90392#2362327 <https://reviews.llvm.org/D90392#2362327>, @lebedev.ri wrote:

> In D90392#2362308 <https://reviews.llvm.org/D90392#2362308>, @ckennelly wrote:
>
>> In D90392#2362118 <https://reviews.llvm.org/D90392#2362118>, @njames93 wrote:
>>
>>> IIUC, this is handling the case where `Ptr.reset(new int)` which is different to `Ptr.reset(new int())` because the former doesn't initialise the int while the latter default(zero) initialises it.
>>> If that's correct I still think we should still warn about this case, but don't suggest an auto-fix as that will change behaviour.
>>> Maybe put a note explaining why it can't be auto-fixed.
>>
>> I disagree with printing a warning but not a fix.
>>
>> These uses should migrate to `std::make_unique_for_overwrite`/`std::make_shared_for_overwrite`.  I am planning on sending a follow-up patch for that but want to avoid the existing make-unique/make-shared checks try to migrate default initialization use cases.
>
> Reminder that there is more than one version of C++ standard, and users are not obligated to be using some particular version, and the checks should not be making that decision for user.

Understood, but replacing `std::unique_ptr<int>(new int)` with `std::make_unique<int>()` does change program behavior.  Once the code migrates to value initialization, it can be hard to determine later whether that initialization ends up being unnecessary when C++20 or an analogue for `std::make_unique_for_overwrite` is available.

I'm hesitant to nudge users towards the behavior change when alternatives would be available (maintain the status quo, have C++20, preadopt a `make_unique_for_overwrite` helper like we do with this clang-tidy for pre-C++14 builds).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90392/new/

https://reviews.llvm.org/D90392