<div dir="ltr">Aaron,<div><br></div><div>Did you have a chance to look at the patch? I have tried to reach you via the comments section but haven't got any reply yet. </div><div><br></div><div>Best regards,</div><div>Carlos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 20, 2021 at 3:07 PM Carlos Galvez <<a href="mailto:carlosgalvezp@gmail.com">carlosgalvezp@gmail.com</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">Here it goes! <a href="https://reviews.llvm.org/D114317" target="_blank">https://reviews.llvm.org/D114317</a><div><br></div><div>As I wrote in the commit message, please take it with a grain of salt - the code is not pretty and many things are missing - I'll take care of that if/when we are happy with the general direction. Looking forward to your feedback! If you have suggestions for the missing bits I'd be very happy to hear them.</div><div><br></div><div>/Carlos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 18, 2021 at 1:46 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</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">On Wed, Nov 17, 2021 at 7:36 AM Carlos Galvez <<a href="mailto:carlosgalvezp@gmail.com" target="_blank">carlosgalvezp@gmail.com</a>> wrote:<br>
><br>
> Hi again!<br>
><br>
> I've been looking into this for a while now and have some very crude proof-of-concept that seems to work without any impact for check developers and ensuring only "perfect aliases" are not run. The only things I can't get around are diagnostics and profiling, so I'd need some help to figure that out (or drop the requirements). Should I push this proof-of-concept for review and continue the discussion there, or do you prefer to discuss here in the mailing list?<br>
<br>
If you've got a proof of concept, I think it's probably worth showing<br>
at this point. (Just as an FYI for setting expectations, my review<br>
time is pretty limited for the next while.)<br>
<br>
~Aaron<br>
<br>
><br>
> Best regards,<br>
> /Carlos<br>
><br>
><br>
> On Mon, Oct 4, 2021 at 9:03 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>><br>
>> On Mon, Oct 4, 2021 at 2:30 PM Carlos Galvez <<a href="mailto:carlosgalvezp@gmail.com" target="_blank">carlosgalvezp@gmail.com</a>> wrote:<br>
>> ><br>
>> > I think we agree in the goals of this change, perhaps it gets confusing when using the term "alias" with different meanings, so let me summarize what I believe is the requirements of what we want to have, without entering in technicalities:<br>
>> ><br>
>> > * All publicly documented checks should be "first-class checks", meaning users can be enable/disable them independently of each other. Not the scope of this change to deprecate the concept/name of "alias", perhaps in the future.<br>
>><br>
>> +1. To be super clear, I consider checks which redirect their<br>
>> documentation to still count as "publicly documented checks".<br>
>><br>
>> > * Users don't need to know/care how these checks are implemented. If they reuse code or not, that's not their concern. They just need to care that their code will get checked properly when the check is enabled, so that they can fix bugs, improve code quality or be compliant with a given guideline.<br>
>><br>
>> +1<br>
>><br>
>> > * Check developers should keep their exact same development flow, and be able to reuse code if possible as they do today.<br>
>><br>
>> +1<br>
>><br>
>> > * Identical checks should run only once. The definition of "identical" is: a) they have the same implementation and b) they have the same configuration. Same implementation but different configuration is not identical checks, so they would all still be run. So the scope is smaller than what it might have looked like in my first post, I hope it's clear now.<br>
>><br>
>> +1<br>
>><br>
>> > * Two additional points of discussion: diagnostics and profiling. IMO implementing this change would be easier if we just skipped diagnostics and profiling for the not-run "identical" checks. We have a list of all checks, then remove the identical ones and run the updated list of checks. Keeping diagnostics and profiling info would probably complicate the design of the tool, but maybe someone has clever ideas. From a user perspective, I think it's neat to avoid diagnostics from identical checks, since it's less noisy to NOLINT them in code.<br>
>><br>
>> Regarding diagnostics, what I'm hoping we can do is keep the<br>
>> diagnostic behavior we already have. e.g.,<br>
>> <a href="https://godbolt.org/z/ss4eKsadb" rel="noreferrer" target="_blank">https://godbolt.org/z/ss4eKsadb</a> where the diagnostic says:<br>
>><br>
>> warning: found assert() that could be replaced by static_assert()<br>
>> [cert-dcl03-c,misc-static-assert]<br>
>><br>
>> and lists both of the ways in which the diagnostic can be triggered<br>
>> but does not show hicpp-static-assert which is a third way to trigger<br>
>> the diagnostic (but was never enabled). I think this is useful because<br>
>> not listing the identical checks can potentially cause some pain for<br>
>> users depending on how they fix the diagnostic or migrate their code.<br>
>> While this one would be most sensible to just change the code, it's<br>
>> not unthinkable that a developer will add a `// NOLINT` comment to<br>
>> disable the diagnostic. If they're only shown one check name in the<br>
>> diagnostic, the user may elect to write `// NOLINT(cert-dcl03-c)` to<br>
>> disable *only* the check name they see. They'll be rather surprised if<br>
>> they decide to drop checking the CERT module and they start getting<br>
>> diagnostics on that line about misc-static-assert when the code was<br>
>> previously suppressing the warning. Seeing multiple checks that<br>
>> trigger will hopefully help the user to know to write `// NOLINT`<br>
>> instead of a specific check, or may help gently guide them towards<br>
>> fixing their code instead of suppressing the diagnostic.<br>
>><br>
>> That said, if this turns out to be an implementation burden in<br>
>> practice, I think the behavior is fine *so long as* the user who adds<br>
>> `// NOLINT(cert-dcl03-c)` doesn't have the experience of silencing the<br>
>> cert diagnostic while still emitting the misc diagnostic (which, if<br>
>> we're not running the duplicate check in the first place, shouldn't<br>
>> happen anyway).<br>
>><br>
>> > Would you agree on the above?<br>
>><br>
>> I think we're in agreement, yes!<br>
>><br>
>> ~Aaron<br>
>><br>
>> > > So the primary check gets all the options that users can tweak, and then coding style checks set those tweakable options as they see fit<br>
>> > Thanks, this helps me understand the design. Makes sense to have a "core" implementation of the check with knobs that can be tweaked via config for each guideline. I have some thoughts about build system and where to put such "common" checks that are re-usable, but let's leave that for another time :)<br>
>> ><br>
>> > On Mon, Oct 4, 2021 at 4:35 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>> >><br>
>> >> On Sun, Oct 3, 2021 at 8:48 PM Carlos Galvez <<a href="mailto:carlosgalvezp@gmail.com" target="_blank">carlosgalvezp@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > > Making it easier<br>
>> >> > for users to enable all of the checks at once requires check authors<br>
>> >> > to consider *all* interactions between modules, and to date that isn't<br>
>> >> > a price we've been willing to make check authors pay. Instead, we<br>
>> >> > typically view modules as being orthogonal sets of functionality that<br>
>> >> > may or may not play well together.<br>
>> >> ><br>
>> >> > Fully agree to that, checks should absolutely be independent, granular and focused on doing one single thing without depending on one another. And they may conflict with each other. My point is that it should be the user making the decision as to how to handle conflicts, enabling and disabling whichever checks they want. Why is that a problem?<br>
>> >><br>
>> >> I am not convinced that it's the right granularity. We've developed<br>
>> >> aliases with the idea that as far as the user is concerned, which is<br>
>> >> primary and which is aliased should not matter. Now we want to change<br>
>> >> that with a blanket switch that impacts all aliases. This isn't a<br>
>> >> problem per se, but I'm not convinced we're ready to add a switch to<br>
>> >> disable all aliases yet.<br>
>> >><br>
>> >> > We are not requiring extra work on LLVM developers.<br>
>> >><br>
>> >> We certainly are requiring extra work for check developers because now<br>
>> >> they have to consider whether to make a check an alias or not because<br>
>> >> that now matters to how their check is surfaced to users.<br>
>> >><br>
>> >> > Why should they have a say on how the user configures the tool? If developers have exposed this public CLI/config interface, users are free to use it as they see fit (and pay the price of their choices, of course).<br>
>> >> ><br>
>> >> > > You're proposing to make aliases be sort of second-class checks<br>
>> >> ><br>
>> >> > Hmm, not exactly, I agree with you that all publicly documented checks should be regarded as "first-class" checks. What I'm proposing here could be considered more as an "optimization" - don't run the same check twice, just re-use previous results. If you know that you are going to run 2 checks that are identical, just run one of them.<br>
>> >><br>
>> >> I think that functionality is a good first step. If it's limited to<br>
>> >> only checks that are *identical*, then my concerns largely go away.<br>
>> >> But I had the impression that the desired scope was larger -- to avoid<br>
>> >> running checks that are identical when ignoring the default<br>
>> >> configurations of the checks -- and that difference is the bit that<br>
>> >> worries me.<br>
>> >><br>
>> >> > > we've never really cared which module has the primary check and which one has the alias check<br>
>> >> > I actually think this is one of the problems that you were concerned about above. Today, not all checks are first-class. There are "primary" checks and "alias" checks, and a decision has to be made as to where to put which, which causes the very issues you are describing. Not all checks from cppcoreguidelines are "primary", some come from "misc", so what? They aren't any less valuable.<br>
>> >><br>
>> >> Today, all checks are first-class as far as the user running the tool<br>
>> >> is concerned. We mention aliases in public so users are aware that<br>
>> >> they exist and to ease documentation burdens (maybe that was a<br>
>> >> mistake), but users don't have to care which one is primary and which<br>
>> >> ones are secondary when they run the tool. So long as we keep that<br>
>> >> property, I'm content.<br>
>> >><br>
>> >> > I refer to my question above - why do we even need this distinction between "primary" and "alias", i.e. what problem is this solving? There's 3 checks checking for C style arrays? That's great, why not just link them to the same documentation, and internally (not leaked to the user) use the same implementation?<br>
>> >><br>
>> >> That's the whole goal of aliases. You bring up a good point on whether<br>
>> >> we need users to know about them at all.<br>
>> >><br>
>> >> > The only use case I can think of to publicly document that there are "alias" checks is to let the user know that they can "skip redundant checks" by manually disabling them. If there's any other use case I'd be very happy to know!<br>
>> >><br>
>> >> They're a convenience for developing a check once but varying its<br>
>> >> behavior across modules, as this use case comes up somewhat frequently<br>
>> >> with coding standards. So the primary check gets all the options that<br>
>> >> users can tweak, and then coding style checks set those tweakable<br>
>> >> options as they see fit. However, this possibly doesn't require the<br>
>> >> user to know about the check being an alias. And there's no benefit to<br>
>> >> running a check twice when it's configuration is identical to a<br>
>> >> previous check that I can tell.<br>
>> >><br>
>> >> ~Aaron<br>
>> >><br>
>> >> ><br>
>> >> > /Carlos<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Sun, Oct 3, 2021 at 6:19 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>> >> >><br>
>> >> >> On Sun, Oct 3, 2021 at 11:24 AM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>> >> >> > To date, aliases have been surfaced to the user as a first-class check<br>
>> >> >> > (while the documentation typically redirects to the primary check for<br>
>> >> >> > simplicity of writing check aliases, there's no requirement that they<br>
>> >> >> > do so; other than that, aliases should behave the same as any other<br>
>> >> >> > check as far as the user is concerned.) You're proposing to make<br>
>> >> >> > aliases be sort of second-class checks that are more closely tied to<br>
>> >> >> > the primary check by providing an option that says aliases are<br>
>> >> >> > disabled as a blanket operation rather than a case-by-case basis. I am<br>
>> >> >> > not convinced this is a good approach. We may already have checks for<br>
>> >> >> > which this is a problem (where the aliased check and the primary check<br>
>> >> >> > are checking different things), and this closes off the design space<br>
>> >> >> > for such checks in the future (and possibly encourages less code reuse<br>
>> >> >> > in the process).<br>
>> >> >> ><br>
>> >> >> > Btw, I'm not saying "no way", I'm saying "let's make sure we're not<br>
>> >> >> > regressing functionality or painting ourselves into a corner."<br>
>> >> >><br>
>> >> >> Also, to date I believe we've never really cared which module has the<br>
>> >> >> primary check and which one has the alias check (it's fine for the<br>
>> >> >> primary to be in cert- and the alias to be in bugprone- or vice<br>
>> >> >> versa), but with this sort of an option, that implementation detail is<br>
>> >> >> leaked out to the user in a more obvious way. If we go this route, we<br>
>> >> >> might have to move some checks around so there's some consistent rule<br>
>> >> >> to aid users (like, the general-purpose module holds the primary and<br>
>> >> >> the coding style guidelines get the alias), but it may not work in<br>
>> >> >> every situation (I can imagine a check living in two style guides but<br>
>> >> >> not a general purpose module, or two general purpose modules but not a<br>
>> >> >> style guide).<br>
>> >> >><br>
>> >> >> ~Aaron<br>
</blockquote></div>
</blockquote></div>