Skip to content
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

Low priority: Unwanted compiler-internal generated types in output #1784

Closed
tamlin-mike opened this issue Nov 5, 2019 · 6 comments
Closed
Labels
C# Decompiler The decompiler engine itself New Feature
Milestone

Comments

@tamlin-mike
Copy link

src

class C {
  unsafe static void tst<T>(System.Span<T> s) where T: unmanaged
  { fixed (T* p = &s.GetPinnableReference()) {} }
}

It seems you can't just use the csc compiler to generate a core3.0 library from a single file (at least I didn't find a way), and I was unable to find a standalone exe suggesting it was a compiler. Easiest workaround I found (which is still a mess) was the following

  • dotnet new classlib -f netcoreapp3.0 -n foo
  • Copy src to foo\Class1.cs
  • dotnet build -p:AllowUnsafeBlocks=True foo\foo.csproj

That should generate foo\bin\Debug\netcoreapp3.0\foo.dll.

This displays a few compiler-embedded types ILSpy should become aware of, and probably not include when producing a project:

  • Microsoft.CodeAnalysis.EmbeddedAttribute
  • System.Runtime.CompilerServices.IsUnmanagedAttribute

Since they are (one would hope) carved in stone, typenames can be hard-coded in ILSpy.

I've also come across System.Runtime.CompilerServices.IsReadOnlyAttribute generated like this, that not only should not be included in the output, its references in decompiled code should also not be included. I've only seen it applied to specific parameters. It could be for to the "ref readonly" construct, but I have been unable to get any tested compiler to accept such a construct so I can't say for certain.

@siegfriedpammer
Copy link
Member

See #829: This is C# 7.3 Custom fixed statement: Types that implement a suitable GetPinnableReference can be used in a fixed statement. Currently not supported by the decompiler.

@siegfriedpammer siegfriedpammer added C# Decompiler The decompiler engine itself New Feature labels Nov 5, 2019
@tamlin-mike
Copy link
Author

I'm not sure if I explained the core issue. GetPinnablein the body was just to display one use of it.
The core issue is the : unmanaged (and the other mentioned) tags making the compiler generate the mentioned attribute classes in the target assembly, classes that should not be included in decompiled output.

@MeFisto94
Copy link

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.isreadonlyattribute?view=net-5.0 is certainly something I am also affected by, decompiled classes just have that annotation on some private structs especially, which causes issues when trying to recompile because:

[CS8335] Do not use 'System.Runtime.CompilerServices.IsReadOnlyAttribute'. This is reserved for compiler usage.

@siegfriedpammer
Copy link
Member

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.isreadonlyattribute?view=net-5.0 is certainly something I am also affected by, decompiled classes just have that annotation on some private structs especially, which causes issues when trying to recompile because:

[CS8335] Do not use 'System.Runtime.CompilerServices.IsReadOnlyAttribute'. This is reserved for compiler usage.

Would you be able to provide us with an assembly and reproduction steps? (preferably open a new issue) thanks!

@siegfriedpammer
Copy link
Member

I've also come across System.Runtime.CompilerServices.IsReadOnlyAttribute generated like this, that not only should not be included in the output, its references in decompiled code should also not be included. I've only seen it applied to specific parameters. It could be for to the "ref readonly" construct, but I have been unable to get any tested compiler to accept such a construct so I can't say for certain.

@tamlin-mike are the uses of these attributes still not removed from the decompiled output? The decompiler should already support (ref) readonly structs and "in" parameters.

We'll have to think about adding a transform that removes the declaration of these attributes when producing a project.

@tamlin-mike
Copy link
Author

Quick test using ILSpy 22c9801 (Nov 6, 2021).

dotnet new classlib -o Tst1
cd Tst1
Place into Class1.cs: public class C1{public void foo<T>(in T t) where T:unmanaged{}}
dotnet build
ilspy bin\Debug\net5.0\Tst1.dll decompiles C1 properly, but saving to project still includes
Microsoft\CodeAnalysis\EmbeddedAttribute.cs
System\Runtime\CompilerServices\IsUnmanagedAttribute.cs

@siegfriedpammer siegfriedpammer added this to the 8.0-preview3 milestone Nov 4, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C# Decompiler The decompiler engine itself New Feature
Projects
None yet
Development

No branches or pull requests

3 participants