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

[Richard Smith via cfe-dev]

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/f08a63bd/attachment.html>