[cfe-dev] Challenging "-Wctad-maybe-unsupported" for 9.0.0

[JVApen via cfe-dev]

On Sun, 4 Aug 2019 at 17:02, Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
wrote:

> On Sun, Aug 4, 2019 at 5:25 AM JVApen <JVApen at gmail.com> wrote:
>
>> On Sun, 4 Aug 2019 at 00:37, Eric Fiselier <eric at efcs.ca> wrote:
>>
>>> On Sat, Aug 3, 2019 at 10:14 AM Arthur O'Dwyer via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> On Sat, Aug 3, 2019 at 6:03 AM JVApen via cfe-dev <
>>>> cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I'm currently testing 9.0.0 and I'm one of those strange people that
>>>>> uses -Weverything in production, as we only support a single clang-release
>>>>> at the same time. (Actually clang-cl, as it's Windows-only)
>>>>> During the upgrade, I've noticed a new warning
>>>>> "-Wctad-maybe-unsupported".
>>>>> At first, I was really happy seeing it and started updating some code
>>>>> that implicitly used it.
>>>>>
>>>>
> Rewinding a bit: JVApen, could you explain a bit about why you felt the
> need to "update" code that used CTAD?
> Also, you said "implicitly used" — is there any difference in your mind
> between "implicitly using" CTAD and "explicitly using" CTAD? What would the
> latter look like?
>
At the moment, I don't have much reason to decide going either way. I'm
trying to understand this new warning and if it's useful in our case.
As I'm testing 9.0.0-RC1, I just want the warnings-as-error to disappear to
tackle the actual issues.
For the implicit part: As mentioned earlier, we didn't communicate about
CTAD when introducing C++17, so right now I assume it's all implicitly
introduced. For sure some are explicit by the few developers that follow
the news about C++ standardization. I was planning to find out on Monday.


>
> Over half of the updates I had to do were about `std::unique_lock`,
>>>>> `std::scope_guard` ... (and this without actively using this feature).
>>>>>
>>>>
> This implies that there were also some cases where people were using CTAD
> on types that weren't unique_lock or [I assume you meant
> scoped_lock/lock_guard, not scope_guard]. What's your opinion of those
> cases? While updating the code, did you find any usages of CTAD that were
> actually incorrect and/or unintentional?
> How would you tell whether a use of CTAD was intentional or unintentional?
>
> See previous: At the moment, I don't.


>
> The situation for me is exactly analogous to VLAs in C — including the
>>>> shape of the workaround: "write an explicit call to malloc()" versus "write
>>>> an explicit call to make_foo()".
>>>> https://reviews.llvm.org/D54565 implements a `-Wctad` warning
>>>> analogous to `-Wvla`.
>>>>
>>>
>> I'm not sure we are talking about the same thing here, from what I read
>> in that review, it flags all usages of CTAD. While the warning I mentioned
>> doesn't trigger if the deduction guide exists. Although both use-cases are
>> relevant, I'm in the luxurious position of having a single C++ standard to
>> work with (and worry about).
>>
>
> In my experience, the existence of a deduction guide (written by the
> library programmer, reflecting only the extent of the library programmer's
> imagination) has no bearing on whether any particular usage of CTAD
> (written by the client programmer, often indicating a typo or thinko) is
> correct or not.
> https://godbolt.org/z/_EfVON
>
> –Arthur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190804/d778c379/attachment.html>