[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