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

xUnit2007 code fix leads to CS8920 compiler error #2798

Closed
boerdereinar opened this issue Oct 22, 2023 · 4 comments
Closed

xUnit2007 code fix leads to CS8920 compiler error #2798

boerdereinar opened this issue Oct 22, 2023 · 4 comments

Comments

@boerdereinar
Copy link

xUnit2007 warns to change Assert.IsAssignableFrom(typeof(IInterface), new Class()); into Assert.IsAssignableFrom<IInterface>(new Class());. However this is impossible and results in a CS8920 compiler error because interfaces with virtual static members cannot be used as a type parameter.

Repro

public class Repro
{
	[Fact]
	public void Test()
	{
		// xUnit2007
		Assert.IsAssignableFrom(typeof(IInterface), new Class());

		// Code fix => CS8920
		// Assert.IsAssignableFrom<IInterface>(new Class());
	}

	private interface IInterface
	{
		static abstract void Test();
	}

	private class Class : IInterface
	{
		/// <inheritdoc />
		public static void Test() { }
	}
}
@etherfield
Copy link

I did some research on the issue. A year ago there was a long discussion on whether to disallow static abstract members as type parameters for generics or not, and apparently now it's a part of .NET 7.0, C#11 (and C# 10 preview).

Clearly, .NET Framework does not support it. I think we can take advantage of notifying user about xUnit2007 if there is a static abstract member for any target runtime though. If the construction is not supported, there would be a compile error in the first place, so skipping xUnit2007 doesn't matter.

@etherfield
Copy link

PR: 167

@bradwilson
Copy link
Member

This is still not a mainline language feature as the issue is still open: dotnet/csharplang#4436

As such, I'm reluctant to merge the proposed fix, even though it seems simple enough, because we generally don't track previews for concerns that the proposal might be rejected and/or whatever code we add may be wrong in the face of the evolution of the feature.

@bradwilson
Copy link
Member

Available in 1.6.0-pre.7

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

3 participants