-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Tests for float- and double- backed Enums #29266
Comments
I see something like this and I wonder, how did this even come to exist in the first place when it's a thing that the CLR spec disallows? |
It was not always disallowed. https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/shared/System/Enum.cs#L18 explains the history. |
The tests for this behaviour were added after the fact, probably in good faith. The fact that they test incorrect behaviour is what bother me though. I implemented support for these Enums in Mono, but I also fixed the bugs in parsing/sorting and now it makes the tests fail. I don't think there's any value in testing bug-for-bug compatibility here. |
I agree that it does not make sense to be testing bug-for-bug compatibility. Does Mono use the parsing/sorting implementation from shared partition? I would be fine to update parsing/sorting implementation or tests to have more sensible behavior for these. (Including changing the obviously broken cases to throw instead of returning wrong result.) As for disallowing the float/double (and intptr/uintptr - they are in a very similar boat) backed enums in the type loader, it has a good chance of breaking boutique languages or obfuscated code. I would do that only if we get something significant that can justify the break in return. |
It uses the code from shared partition, but these particular cases are handled in the non-shared code. Notably, CoreCLR sorts the names/values in native code (https://github.com/dotnet/coreclr/blob/d3e39bc2f81e3dbf9e4b96347f62b49d8700336c/src/vm/reflectioninvocation.cpp#L2822-L2826), while Mono does it in managed code (https://github.com/mono/mono/blob/b1af4c2726cdc211971efacee7d66a6e447336d2/mcs/class/System.Private.CoreLib/System/Enum.cs#L118-L119). I intentionally broke the sorting in Mono to match the tests, but I can reinstate it by changing one line. The parsing is also happening in native code in Mono. I didn't find where the values in CoreCLR come from. Would it make sense if I compile a list of the "broken" test cases? |
You say that as if it's a bad thing... |
For these in particular, it is worth noting that even the current spec currently allows it (unlike
|
Sounds good to me. |
It is if you rely on it working. 😃 |
That's the thing. I don't want obfuscated code working, especially when one of the biggest use cases for it these days is for malware authors to make their malicious code harder to reverse-engineer! |
Here's the list of tests that fail on Mono implementation:
Six of them are related to sorting in ReflectionEnum::GetEnumValuesAndNames. Four of them rely on incorrect results from parsing. |
What is different in this sorting in Mono that makes it work right? I am not able to tell by just looking at the code.
Does Mono parses these correctly? |
It actually sorts the values for R4- and R8-typed enums. CoreCLR returns them in declared order.
Yes, as far as I can tell. Mono parses case-insensitive "vaLue2" to "Value2" that is in the enum definition. CoreCLR seems to always return the first element of the enum. |
The current code in Mono is intentionally broken to pass the test. I'll post links to the relevant parts and explanations once I get back to my computer. |
Here's the list of relevant Mono code that causes the different sorting behaviour:
I don't have explanation for the the CoreCLR difference in the parsing tests. Couple of the tests rely on the unsorted enums and access the values as I'll publish my Mono changes in a branch in case I missed something and link it here. |
/cc @marek-safar |
@stephentoub @danmosemsft what is your preferred way to resolve this issue? |
@marek-safar in the near term I think it is fine to disable these as @EgorBo is already doing. The actual runtime behavior we want seems a corner case discussion we can defer. I'd be inclined to say that both runtimes can just keep doing what they're doing unless and until we get customer feedback that they depend on the behaviors and then we might want to try to make them consistent. |
Tagging subscribers to this area: @tannergooding |
…bles This change avoids allocation of the temporary ulong[] array during EnumInfo initialization Fixes dotnet#29266
* Add generic Enum.TryFormat method * Rewrite Enum using generic specialization per underlying type Also revises the shape of the newly added Enum.TryFormat method and fixes tests accordingly. * Use Enum.TryFormat in interpolated string handlers * Implement ISpanFormattable on Enum * Use generic Enum methods in more places * Replace Unsafe.As with unmanaged pointers where possible Reduces cost of the generic methods * Simplify Enum_GetValuesAndNames QCall, fix handling of floats and doubles This change avoids allocation of the temporary ulong[] array during EnumInfo initialization Fixes dotnet/runtime#29266 * Fix mono's GetEnumNamesAndValues, and make ToObject handle float/double as well * Fix perf gap and polish * Undo update of Enum.GetTypeCode to include float/double * Address PR feedback * Accomodate net8.0 TFM update * Fix InvalidCastException from GetEnumValues on mono when dealing with bool-based enums Co-authored-by: Heath Baron-Morgan <[email protected]> Co-authored-by: Jan Kotas <[email protected]> Commit migrated from dotnet/runtime@62f3eb2
There are numerous test for
Enum
types backed byfloat
ordouble
in EnumTests.cs and EnumTests.netcoreapp.cs.The ECMA specification doesn't allow these
Enum
types:(ECMA CLR standard, §II.14.3)
Moreover, in many cases the tests actually expect a broken behaviour like incorrect parsing of values or
Enum.GetNames
/Enum.GetValues
not returning results sorted by the values:https://github.com/dotnet/corefx/blob/10d7d6f812295a572eb148aedb19efd2f96fbe17/src/System.Runtime/tests/System/EnumTests.cs#L90-L96
I believe these tests should be removed, CoreCLR should not allow float- and double- backed enums and there should be test verifying that such enums cannot be created.
/cc @jkotas
The text was updated successfully, but these errors were encountered: