[llvm-dev] "[NFC]" Abuse

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 21 10:34:30 PDT 2021


On 6/21/21 10:27 AM, David Blaikie via llvm-dev wrote:
> On Sun, Jun 20, 2021 at 4:41 PM Joerg Sonnenberger via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     On Thu, Jun 17, 2021 at 03:13:16PM -0400, John McCall via llvm-dev
>     wrote:
>     > Yeah, I expect NFC changes to be purely internal implementation
>     > details.  Changing the public interface (even to add a feature)
>     > isn’t NFC; neither is anything that can affect output.
>
>     I would consider an even more restricted subset: NFC changes would be
>     trivial proven to be just that. That means non-trivial algorithmic
>     changes are certainly not NFC. My point is that the tag should be
>     applied with care only and if there is any doubt, it should not be
>     used
>     at all.
>
>
> I disagree pretty strongly there - intent is important and all any 
> patch comment can describe.
>
> If that change was adopted, I'd want another flag for the "I intend 
> this not to change the observable behavior, but it's not trivially 
> proven" - especially when reviewing a patch that is missing test 
> coverage. If someone hasn't made a claim that this doesn't change 
> behavior, then I expect that the inverse is true (it does change 
> behavior) and a test should be present. And once we have that flag, 
> I'm not sure the difference between "I intend this to not change 
> behavior, but it passes some threshold of triviality that makes it not 
> 'guaranteed'" and things below that threshold is sufficiently valuable 
> to encode in the commit message (& haggle over which things are over 
> or under that threshold).

+1

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210621/5bf5920f/attachment.html>


More information about the llvm-dev mailing list