<div dir="auto">Thanks all!<div dir="auto"><div dir="auto"><br></div><div dir="auto">I totally agree with Richard about the functionality making sense. The more I read about CTAD, the more I see value in this warning.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thanks for all of your time!</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 4, 2019, 22:55 Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 3 Aug 2019 at 03:03, JVApen via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Hello all,<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">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)<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">During the upgrade, I've noticed a new warning "-Wctad-maybe-unsupported".<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">At first, I was really happy seeing it and started updating some code that implicitly used it.</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">I'm even considering to propose an extension to our styleguide, as mentioned in the review of the warning: <a href="https://reviews.llvm.org/D56731" target="_blank" rel="noreferrer">https://reviews.llvm.org/D56731</a></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">`Some style guides want to allow using CTAD only on types that "opt-in"`<br></div><div><br></div><div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">However, after finishing my initial testing and applying some suppression and update locally, I'm changing my mind.<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Over half of the updates I had to do were about `std::unique_lock`, `std::scope_guard` ... (and this without actively using this feature).<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">These classes, if I'm correct, are one of the selling point of CTAD and are prohibited thanks to this warning.</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">To circle back to title of the email, should -Wctad-maybe-unsupported actually be a compiler warning iso a clang-tidy check?<br>If so, would it make sense of having a white-list, like all `std::` classes?<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><br></div><div><br></div><div><br></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>
</blockquote></div>