[Mono-bugs] [Bug 668386] [post] Should allow reporting items which were ignored without affecting the final exitCode

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Sun Apr 3 12:12:01 EDT 2011


https://bugzilla.novell.com/show_bug.cgi?id=668386

https://bugzilla.novell.com/show_bug.cgi?id=668386#c4


Sebastien Pouliot <spouliot at novell.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Should allow reporting      |[post] Should allow
                   |items which were ignored    |reporting items which were
                   |without affecting the final |ignored without affecting
                   |exitCode                    |the final exitCode

--- Comment #4 from Sebastien Pouliot <spouliot at novell.com> 2011-04-03 16:12:00 UTC ---
> Not sure I get completely the idea of how to fix this enhancement with
post-processing tools

Simply put: runners takes assemblies and return a defect list [1]

If additional inputs helps to reduce/simplify the analysis then it's a great
runner feature. Ignore-list is such a case because it can avoid code analysis
since we know we'll ignore its result.

i.e. running rule X on code Y, leading to known defects, which means
allocations, not a simple DoesNotApply... that saves time/memory


In contrast options that requires extra conditions to occurs before rules are
executed are *very* costly. 

E.g. an extra check to call IRule::Check* methods would be called millions of
time on Mono class libraries. Since most rules will return quickly
(DoesNotApply) then the extra check needs to be ***very*** cheap not to affect
performance.

In fact it's often [2] quicker to get defects (even several thousands) then
post-process them (with the extra logic) than applying it on the millions
Assemblies/Types/Methods.

Now consider that each new idea is a (or several) new check(s), that only some
Gendarme users will need, or need only some time...


[1] various formats (but that's something that could be post-processed, anyway
reporting occurs after the analysis)

[2] *often* is for people that will use the feature since it's always quicker
for people that do not require it ;-)



p.s. please do not undo previous bug (description) changes :)

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the mono-bugs mailing list