[Mono-bugs] [Bug 665179] New: AvoidVisibleFieldsRule should not fire on a public (or public static) EventHandler<T> with default implementation

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Tue Jan 18 11:26:45 EST 2011



           Summary: AvoidVisibleFieldsRule should not fire on a public (or
                    public static) EventHandler<T> with default
    Classification: Mono
           Product: Mono: Tools
           Version: 2.10.x
          Platform: 64bit
        OS/Version: Windows 7
            Status: NEW
          Severity: Enhancement
          Priority: P5 - None
         Component: Gendarme
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: ethan_j_brown at hotmail.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.634.0 Safari/534.16

Default EventHandler<T> add/remove generated by the compiler is thread-safe.

>From the spec
When compiling a field-like event, the compiler automatically creates storage
to hold the delegate, and creates accessors for the event that add or remove
event handlers to the delegate field. In order to be thread-safe, the addition
or removal operations are done while holding the lock (§8.12) on the containing
object for an instance event, or the type object (§ for a static

More info

There are a number of places in the BCL where EventHandler<T> is exposed
publicly -- for instance there is a static EventHandler<T> in 


In most cases, a private EventHandler<T> is used, but I don't believe that
adding a private member of the same type and implementing the add/remove is
actually a breaking change should there be a need in the future to change the
default add/remove behavior generated by the compiler.

Reproducible: Always

Steps to Reproduce:
Actual Results:  
AvoidVisibleFieldsRule defect is generated

Expected Results:  
No defect for this use case.

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