https://bugzilla.novell.com/show_bug.cgi?id=668386
https://bugzilla.novell.com/show_bug.cgi?id=668386#c4 Sebastien Pouliot <[email protected]> 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 <[email protected]> 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
