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

[Arthur O'Dwyer via cfe-dev]

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.
> 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?
>

(You mean "should -Wctad-maybe-unsupported be a clang-tidy check instead of
a compiler warning?", I assume.)


> If so, would it make sense of having a white-list, like all `std::`
> classes?
>

FWIW, I continue to believe that it makes no sense to talk about the *library
author* "opting in" to CTAD. Either the *client programmer* trusts CTAD
(even if it runs the risk of deducing the wrong thing sometimes) and thus
every set-of-missing-angle-brackets must be assumed to be intentional no
matter what type it's on, or else the client programmer doesn't trust CTAD
(because of the aforementioned risk), and thus every
set-of-missing-angle-brackets must be assumed to be unintentional. The
intentions of the *library author* don't matter at all in this equation.

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`.

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190803/5ab1d35f/attachment.html>