Updating GenAPI to support static abstracts in interfaces and user-defined checked operators

[tannergooding]

This resolves #8639
This resolves #8638

[tannergooding]

Some example diffs.

Previously the "full name" would be used in the corresponding primitive type, there is no need for this and it makes the code needlessly different from the source (e.g. System.Boolean was used in System.Boolean rather than the bool used everwhere else):

- public int CompareTo(System.Boolean value) { throw null; }
+ public int CompareTo(bool value) { throw null; }

Implementations of static abstract members are now correctly processed:

- static System.Byte CreateChecked<TOther>(TOther value) { throw null; }
+ public static byte CreateChecked<TOther>(TOther value) where TOther : System.Numerics.INumber<TOther> { throw null; }

Static abstract operators are now correctly named:

- static System.Byte System.Numerics.IAdditionOperators<System.Byte,System.Byte,System.Byte>.op_Addition(System.Byte left, System.Byte right) { throw null; }
+ static byte System.Numerics.IAdditionOperators<byte, byte, byte>.operator +(byte left, byte right) { throw null; }

[tannergooding]

CC. @adiaaida, @ericstj

[ericstj]

there is no need for this and it makes the code needlessly different from the source

I agree that the change makes things more readable. I wonder if there was any reason behind why it does what it does because someone went out of their way to do that. It's been this way since open sourced, but you might be able to see history in the fxcore repository.

[tannergooding]

I wonder if there was any reason behind why it does what it does because someone went out of their way to do that

AFAIK, there is no reason to ever not prefer the language keyword (modulo using aliases). If there was, I would expect we'd have the same requirement in our actual source implementation.

[tannergooding]

Is this still pending any changes or can it be merged?

[ViktorHofer]

Spoke about your PR with @ericstj yesterday and he offered to help. Unfortunately I can't add any value here as I don't know much about CCI.

[ericstj]

This code change looks ok to me. We don't get great test coverage of this so I had the following suggestion.

Run genapi on the bin directory of dotnet/runtime using the tool prior to this change and after, then diff the result. That can help you understand that your change supports all the places we use it in dotnet/runtime and the diff can make sure you aren't adding any unexpected changes.

I put together a gist of the script to do this: https://gist.github.com/ericstj/1047b60e51dad611d34a72d645b07c9f
And since I had that working I just went ahead and ran it against your branch. Here's the diff: ericstj/scratch@abd4851

@tannergooding can you please review that and make sure all the changes look right to you?

It would also be good to test that consuming this for System.Runtime is working as expected. I didn't go so far as to do that. I tried to compile the output of System.Private.CoreLib.cs and hit a stack-overflow in the compiler but I hit that both before and after your change so its likely something else.

[tannergooding]

It would also be good to test that consuming this for System.Runtime is working as expected.

All the checked in generic-math changes from the past few weeks have been generated using this as the basis, so I'm confident its working as intended.

can you please review that and make sure all the changes look right to you?

I'm not 100% on the Microsoft.VisualBasic.Core changes. It looks like the previous code wasn't even valid?

System.Private.Corelib looks correct. System.Security.Crypto.Cose likewise looks like the previous code was invalid

[tannergooding]

@ericstj anything else needed here or are we good to merge?

[ericstj]

Ok, lets give this a try. TFTF @tannergooding