Remove special handling of EventSource

[vitek-karas]

Linker has some special handling of EventSource types:
https://github.com/mono/linker/blob/55bd0ebd00ddbf2cd817314b1cf6824003cfb463/src/linker/Linker.Steps/MarkStep.cs#L1701-L1705

With the changes to support EventSource fully with annotations, this should be removed once the necessary framework changes are made.

[vitek-karas]

/cc @LakshanF

[vitek-karas]

Part of #1349

[LakshanF]

PR #2063 Reverted the earlier checkin and we need to revisit this

[LakshanF]

We cannot remove the special handling of EventSource nested classes easily due to the scenarios like the following

• A non-public EventSource is defined in a library
• No references to nested classes of the EventSource is made inside the library
• There is a reference to the EventSource externally that requires the EventSource manifest to be generated. (the nested types like the Keywords class are needed to generate the manifest).

Specific example for the above scenario is the internal NetEventSource in System.Net.Mail.dll. This test case shows the below error path if we don't have this special handling and remove the nested class like "Keywords",

System.ArgumentException : Use of undefined keyword value 0x1 for event Info.

 at System.Diagnostics.Tracing.ManifestBuilder.ManifestError(String msg, Boolean runtimeCritical) in /_/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs:line 5529
   at System.Diagnostics.Tracing.ManifestBuilder.AppendKeywords(StringBuilder sb, UInt64 keywords, String eventName) in /_/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs:line 5932
   at System.Diagnostics.Tracing.ManifestBuilder.StartEvent(String eventName, EventAttribute eventAttribute) in /_/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs:line 5383
   at System.Diagnostics.Tracing.EventSource.CreateManifestAndDescriptors(Type eventSourceType, String eventSourceDllName, EventSource source, EventManifestOptions flags) in /_/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs:line 3369
   at System.Diagnostics.Tracing.EventSource.GenerateManifest(Type eventSourceType, String assemblyPathToIncludeInManifest, EventManifestOptions flags) in /_/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs:line 401
   at System.Diagnostics.Tracing.EventSource.GenerateManifest(Type eventSourceType, String assemblyPathToIncludeInManifest) in /_/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs:line 371
   at System.Net.Mail.Tests.LoggingTest.EventSource_ExistsWithCorrectId() in /_/src/libraries/System.Net.Mail/tests/Functional/LoggingTest.cs:line 25
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) in /_/src/mono/System.Private.CoreLib/src/System/Reflection/RuntimeMethodInfo.cs:line 378

[MichalStrehovsky]

Is this being stripped during library build?

This sounds like an analysis hole with any DAM placed on classes when illink is running in the special "library mode" (and doesn't have whole program view).

If illink is running in the library mode, it shouldn't wait to see if GetType is ever called on something that was annotated. It should mark things eagerly whenever a subclass of an annotated class is seen.

[LakshanF]

Yes, specifically for the System.Net.Mail.dll with the -a FILE library option,

-a "C:\Work\core\runtime\artifacts\obj\System.Net.Mail\net6.0-windows-Release\PreTrim/System.Net.Mail.dll" library