Removal of debugger attributes causes linker warnings in code which refers to those attributes

[vitek-karas]

With the recent debugger feature switch linker is now tasked to remove some attributes which are related to the debugger. Linker will do that for all attribute instantiations, but if there's code which refers to the removed attribute's type directly, linker will generate a warning since it's likely the behavior of that code will change.

Currently this produces 4 warnings in CoreLib:

ILLink: warning IL2045: System.Diagnostics.StackTrace.ToString(StackTrace.TraceFormat,StringBuilder): Custom Attribute System.Runtime.CompilerServices.CompilerGeneratedAttribute is being referenced in code but the linker was instructed to remove all instances of this attribute. If the attribute instances are necessary make sure to either remove the linker attribute XML portion which removes the attribute instances, or to override this use the linker XML descriptor to keep the attribute type (which in turn keeps all of its instances).
ILLink: warning IL2045: System.Diagnostics.StackTrace.ShowInStackTrace(MethodBase): Custom Attribute System.Diagnostics.StackTraceHiddenAttribute is being referenced in code but the linker was instructed to remove all instances of this attribute. If the attribute instances are necessary make sure to either remove the linker attribute XML portion which removes the attribute instances, or to override this use the linker XML descriptor to keep the attribute type (which in turn keeps all of its instances).
ILLink: warning IL2045: System.Diagnostics.StackTrace.ShowInStackTrace(MethodBase): Custom Attribute System.Diagnostics.StackTraceHiddenAttribute is being referenced in code but the linker was instructed to remove all instances of this attribute. If the attribute instances are necessary make sure to either remove the linker attribute XML portion which removes the attribute instances, or to override this use the linker XML descriptor to keep the attribute type (which in turn keeps all of its instances).
ILLink: warning IL2045: System.Diagnostics.Tracing.Statics.CreateDefaultTypeInfo(Type,List<Type>): Custom Attribute System.Runtime.CompilerServices.CompilerGeneratedAttribute is being referenced in code but the linker was instructed to remove all instances of this attribute. If the attribute instances are necessary make sure to either remove the linker attribute XML portion which removes the attribute instances, or to override this use the linker XML descriptor to keep the attribute type (which in turn keeps all of its instances).

We should either suppress these warnings or wrap the code which does this with the respective feature switch so that it gets removed.

Tagging subscribers to this area: @tommcdon
Notify danmosemsft if you want to be subscribed.

[MichalStrehovsky]

How would a user go about resolving this warning? (I only looked at titles of linker pull requests around this, so I'm as oblivious of this behavior as anyone else).

Querying for CompilerGenerated is actually pretty common (EF does this, ASP.NET does this, Newtonsoft.Json does this - off the top of my head). I think people are going to hit this warning pretty often.

[vitek-karas]

Then we should not blame the warning but rather the attribute.

There are 3 options depending on who the user is:

• Us - we can remove the CompilerGeneratedAttribute from the list of attributes to be removed - that said if I remember correctly this one saved a lot of size (as it's apparently all over the place) - but if we think removing it is too dangerous...
• Library authors - just like any other warning generated by trim analysis the library (for example EF) would need to deal with it. For this attribute there are 2 ways:
  • If it's not necessary for the functionality (like for example the use case in ASP.NET is not necessary, it just makes callstacks look nicer) - suppress the warning via the suppression attribute
  • If it is necessary - add a link descriptor the library and mark the attribute type in it - in this case the CompilerGeneratedAttribute from CoreLib. This is a mechanism we added which overrides the attribute removal - that is if the attribute type is explicitly preserved via a descriptor, linker will keep all the instances of it (Regardless of the attribute removal flags)
• Application developer - similarly to the library author - either ignore/suppress or use the descriptor to force-include it.

Obviously if we find a case inside our framework which would need the attribute to be kept - we should just leave it of from the list of removed attributes instead - but I don't think that's the case in the warnings above.

[MichalStrehovsky]

Would it make sense to hook up the attribute removal into the --used-attribs-only infrastructure in MarkStep?

• If we see an attribute that is of a "removable type", don't mark it, just add it into the lazily marked list.
• If the attribute type ended up getting marked (e.g. because there was a typeof), mark the attributes as well (this is what the --used-attribs-only does too, but the twist would be that we don't let it happen to random attributes, only to those that are in the list).

I.e. in this situation there would be no warning, just the attribute wouldn't be removed, because it's actually used.

In order to allow the attribute to actually be stripped, we would need to make sure the code uses it under feature switches.

It would still have the problem that there could be code that does GetCustomAttributes<Attribute> and they're actually looking for an attribute that we chose to remove, but that problem is orthogonal (it exists in the current solution too - there is no warning from the linker that there is XML that is breaking the app).

[vitek-karas]

Yes - we could do that, that's a good idea. I filed dotnet/linker#1378 to track that.