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

[JVApen via cfe-dev]

Thanks all!

I totally agree with Richard about the functionality making sense. The more
I read about CTAD, the more I see value in this warning.

When I wrote the first email, I wasn't even considering maintaining such a
whitelist in code and wondered if it was at the right place as one could
configure that whitelist in the config file.

I've now drafted a first version of a whitelist myself already, which
doesn't look that terrible to maintain given our way of working. I think
I've seen enough arguments to convince me that making this a clang-tidy
check iso a warning ain't a good idea.

Thanks for all of your time!

On Sun, Aug 4, 2019, 22:55 Richard Smith <richard at metafoo.co.uk> wrote:

> As a general principle: we will not remove a disabled-by-default warning
> just because it's noisy in -Weverything builds. As a user of -Weverything,
> you are expected to turn off the warnings that you don't like. That's the
> deal.
>
> For this warning in particular, we have multiple groups of users that have
> asked for it and see it as essential in order to have a maintainable
> large-scale codebase using CTAD. The warning prevents accidental dependence
> on the implementation details of other people's code, which puts this check
> in the same category as (for instance) access control; generally we want
> that kind of check to be performed in all builds and not done separately by
> a lint tool such as clang-tidy.
>
> The false positives on standard library types (especially in standard
> library implementations we don't control) do seem like a problem, and
> maintaining an explicit list of such types on which the warning is
> suppressed seems like a reasonable solution to me.
>
> On Sat, 3 Aug 2019 at 03:03, 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.
>> I'm even considering to propose an extension to our styleguide, as
>> mentioned in the review of the warning: https://reviews.llvm.org/D56731
>> `Some style guides want to allow using CTAD only on types that "opt-in"`
>>
>> However, after finishing my initial testing and applying some suppression
>> and update locally, I'm changing my mind.
>> Over half of the updates I had to do were about `std::unique_lock`,
>> `std::scope_guard` ... (and this without actively using this feature).
>> These classes, if I'm correct, are one of the selling point of CTAD and
>> are prohibited thanks to this warning.
>>
>> To circle back to title of the email, should -Wctad-maybe-unsupported
>> actually be a compiler warning iso a clang-tidy check?
>> If so, would it make sense of having a white-list, like all `std::`
>> classes?
>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190804/50ef1834/attachment.html>