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

TypeSystem: Support ref structs within generics #65112

Open
11 of 13 tasks
mangod9 opened this issue Feb 10, 2022 · 12 comments
Open
11 of 13 tasks

TypeSystem: Support ref structs within generics #65112

mangod9 opened this issue Feb 10, 2022 · 12 comments

Comments

@mangod9
Copy link
Member

mangod9 commented Feb 10, 2022

This is a top-level issue to track supporting ref structs within generics. For additional details refer to dotnet/csharplang#7608 and the older dotnet/csharplang#1148.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Feb 10, 2022
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@mangod9
Copy link
Member Author

mangod9 commented Jul 13, 2023

@AaronRobinsonMSFT , assume this is ok to close or is there more work required here?

@mangod9
Copy link
Member Author

mangod9 commented Aug 4, 2023

@AaronRobinsonMSFT ping again. Anything remaining for this in 8?

@AaronRobinsonMSFT
Copy link
Member

Only the bare minimum has been done. Moving this to .NET 9.

@tkreindler
Copy link

This feature request would be extremely valuable for unit testing. Right now, when using mocking frameworks like NSubstitute it's impossible to mock out a function that takes a ref-struct type like ReadOnlySpan as an argument.

For example doing the following gives a CS0306 error:

interface IMessage
{
    string DoSomething(ReadOnlySpan<byte>);
}

// Test Code
IMessage message = Substitute.For<IMessage>();

message.DoSomething(Arg.Any<ReadOnlySpan<byte>>()).Returns("success");

NSubstitute and its parent library Castle.Core have investigated this issue in the past and any fixes seem to have stalled out due to the difficulty of doing this without this language feature.

I believe this feature would fix this unit-testing gap and be a big improvement to the dotnet ecosystem.

@lambdageek
Copy link
Member

cc @steveisok

@vitek-karas
Copy link
Member

@AaronRobinsonMSFT - did somebody look if this works with Cecil/Trimmer? It uses different type system and it could get confused on the new pattern.

@AaronRobinsonMSFT
Copy link
Member

@AaronRobinsonMSFT - did somebody look if this works with Cecil/Trimmer?

Not that I am aware of. Can I get someone from your side to try this out? What do we need to do to exercise this path? We have several IL based assemblies with the feature enabled we can pass to other tools.

@vitek-karas
Copy link
Member

@sbomer - we should be able to add tests for illink - the infra has the setup for IL-based tests.
Also round-trip tests of Cecil would be helpful (or through illink, it's kind of the same thing) - to make sure trimmer doesn't corrupt the metadata around this.

@jbevain
Copy link
Contributor

jbevain commented May 21, 2024

Cecil work is at jbevain/cecil#945

@steveisok
Copy link
Member

It looks like everything is done and this issue can be closed. If I'm mistaken, feel free to reopen.

@AaronRobinsonMSFT AaronRobinsonMSFT modified the milestones: 9.0.0, 10.0.0 Aug 5, 2024
@AaronRobinsonMSFT
Copy link
Member

No, sadly this isn't done. After updating the design and ECMA, more work is needed. I moved to 10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants