-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow RequiresUnreferencedCode on classes and structs #1742
Comments
Is that just syntactic sugar to save us from annotating multiple methods or do we expect more semantics from this? E.g. do derived types inherit this setting? Does it propagate to nested types? Putting RequiresUnreferencedCode on some methods is problematic. E.g. annotating a |
Could you link the code you are referring to? I'm not sure this will be useful when used in non-trivial code. I'd expect that constructors and properties rarely need RequiresUnreferencedCode. |
See the |
I don't see that as good evidence that we need it right now. BinaryParser (only 4 internal methods need it out of about 35) |
@agocke Brought this up on our 1:1 yesterday. He suggested a possible semantic for this that might work for this: treat it the same as the C# compiler treats the ObsoleteAttribute. Basically, on classes, it would behave the same as if we annotated all the constructors and static methods as RUC. We would also suppress all trimming warnings within instance methods, but we would not treat them like RUC at their callsites (this avoids the problem of ToString) - this assumes that the unsafe operation is creating the type - after that, all bets are off. It's not easily extensible to structs, but I posit that nobody is going to miss that. One possible complication is static virtual methods that are being added to C# and runtime as we speak. I don't know what the solution for that would be (they allow calling static methods indirectly). Maybe we can say that you can't put the attribute on a type that implements static interface methods and this will be a warning. Or maybe the C# team will come up with something clever. |
I would also assume any usages of the Type, say for example: |
That by itself doesn't look problematic. But if MyGeneric has a We need to be careful about when we generate these warnings because it's easy to get into a situation where "if the type wasn't trimmed away, we will warn" because those are hard to suppress and generate warnings for (e.g. should the fact that a type implements |
Here's another case where it would be beneficial to have We are up to almost 800 |
Was this ever implemented in the linker? I see usages of this trying to pop up. ex. dotnet/runtime#55108. |
@tlakollo is working on it - it's tentatively planned for 6 right now (but no guarantees as we haven't got it working end to end yet). |
Thanks. For now I'll recommend people don't use this feature until it is implemented. If we don't get it in for 6, we need to revert dotnet/runtime#50064 then. |
@tlakollo is working on this right now has his highest priority. Hope to have it available shortly |
@tlakollo Still need analyzer support, right? |
Yes, the Merged PR would only work for Linker |
This should be already working for linker and analyzer see #2330, closing |
Some types are inherently not trim compatible. Take, for example,
BinaryFormatter
. Virtually anything you do with the type is not going to be trim compatible.Today, we only allow
RequiresUnreferencedCodeAttribute
on methods and constructors.https://github.com/dotnet/runtime/blob/d2e1a86434d1c0b74d75604b4cf9fdca100108c3/src/libraries/System.Private.CoreLib/src/System/Diagnostics/CodeAnalysis/RequiresUnreferencedCodeAttribute.cs#L14-L15
When trying to annotate the implementation of
BinaryFormatter
, it is causing almost every method in the library to be marked asRequiresUnreferencedCode
. This is a lot of changes when just putting the attribute on a whole class would be a lot easier.We should change the ILLinker to support
RequiresUnreferencedCodeAttribute
on classes and structs, and possibly interfaces.@agocke @vitek-karas @MichalStrehovsky
The text was updated successfully, but these errors were encountered: