[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]

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

https://bugzilla.novell.com/show_bug.cgi?id=665179#c0


           Summary: AvoidVisibleFieldsRule should not fire on a public (or
                    public static) EventHandler<T> with default
                    implementation
    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 (§7.6.10.6) for a static
event.

More info
http://stackoverflow.com/questions/3522361/add-delegate-to-event-thread-safety


There are a number of places in the BCL where EventHandler<T> is exposed
publicly -- for instance there is a static EventHandler<T> in 
System.Threading.Tasks.TaskScheduler.UnobservedTaskException.

http://msdn.microsoft.com/en-us/library/system.threading.tasks.taskscheduler.unobservedtaskexception.aspx

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:
1.https://github.com/Iristyle/mono-tools/commit/83d31d70a805a11d5ad00543b1a8ae184f7bef33
2.
3.
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.