All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] dim: Avoid false positives with BUG detection
Date: Fri, 18 Mar 2016 15:42:38 +0000	[thread overview]
Message-ID: <56EC21EE.9010203@intel.com> (raw)
In-Reply-To: <877fh1uyx1.fsf@intel.com>

On 17/03/16 11:27, Jani Nikula wrote:
> On Thu, 17 Mar 2016, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>> [ text/plain ]
>>
>>
>> On 11/03/16 15:31, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> Makes sure that the diff line adding the BUG is not immediately
>>> preceded by the diff line removing the BUG. Or in other words,
>>> avoids false positives when existing BUG is edited.
>>>
>>> v2: Sent the incomplete version out...
>>>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> ---
>>>    dim | 3 ++-
>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/dim b/dim
>>> index 1e7622a1e902..5392c64bf5b4 100755
>>> --- a/dim
>>> +++ b/dim
>>> @@ -691,7 +691,8 @@ function shell_checkpatch
>>>    	local cmd=$1
>>>
>>>    	$cmd | scripts/checkpatch.pl -q --strict - || true
>>> -	if $cmd | grep '^\+.*\WBUG' > /dev/null; then
>>> +	local bug_lines=$("$cmd" | grep -m 1 -B 1 '^\+.*\WBUG' | grep -c '^[+-].*\WBUG')
>>> +	if test "$bug_lines" -eq 1; then
>>>    		warn_or_fail "New BUG macro added"
>>>    	fi
>>>    	$cmd | grep '^\+.*drm_i915_private_t' > /dev/null && echo "WARNING: New drm_i915_private_t added" || true
>>>
>>
>> Are we interested in this?
>
> Yes. Sorry, I've updated these lines so you'll need to rebase, I'm
> afraid.
>
> I'd also be fine with comparing the results of $(grep -c '^\+.*\WBUG)
> and $(grep -c '^\-.*\WBUG) and complaining if there are more +'s than
> -'s. But your stricter version is fine too.
>
> BR,
> Jani.

The version above doesn't really avoid all the issues, though; for 
example if the edited BUG spans multiple lines, or if the pattern 
spotted (first added line containing a word beginning with BUG) is in a 
comment or string, or what's actually happened is that some code has 
been moved from before an existing BUG() to after or vice-versa, but 
diff thinks you've deleted the old BUG() and added a new one :(

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2016-03-18 15:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 15:26 [PATCH] dim: Avoid false positives with BUG detection Tvrtko Ursulin
2016-03-11 15:31 ` [PATCH v2] " Tvrtko Ursulin
2016-03-17 10:06   ` Tvrtko Ursulin
2016-03-17 11:27     ` Jani Nikula
2016-03-18 15:42       ` Dave Gordon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56EC21EE.9010203@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.