Allow user-specified underlying type for enums#8329
Allow user-specified underlying type for enums#8329TravisEz13 merged 36 commits intoPowerShell:masterfrom
Conversation
This commit changes the behavior of the DefineEnumHelper, specifically the way the underlying type of the Enum type is specified. 06ff8a3 makes the parser recognize a base type token, this changes the underlying type of the generated EnumBuilder if the base type token corresponds to a builtin CLS value type as specified in ECMA-335 §I.8.5.2 (CLS Rule 7), otherwise it defaults to [int] TODO: - re-introduce range validation - better parsing errors for invalid underlying types
I'm thinking there must be an easier way of abstracting this away, but I can't think of anything
Forgot to reset the tokenizer in a previous commit, causing parsing errors.
Added new context for testing behavior when Flags() is applied. Increased test coverage for all underlying types, added type constraint test
enums can only be based off builtin integral types, parser should report an error if any other kind of type name is passed in
Co-Authored-By: IISResetMe <IISResetMe@users.noreply.github.com>
Given that valid enum underlying types are all resolvable at parse-time (and unlikely to change), we might as well have the Parser error when an invalid underlying type is passed in as a type constraint.
…m/IISResetMe/PowerShell into feature/enum-with-underlying-type
ErrorId updated in @548b6cd3
Since (any valid) input value and maxValue are bound to be of the same type, we may as well mark maxValue dynamic as well - they will be comparable at runtime, and this avoids incorrectly erring when the user specifies a negative integer value for a member
|
Can we get committee review for the new syntax? |
|
@PowerShell/powershell-committee reviewed this and is fine with the syntax |
|
@TravisEz13 Please update your review. |
|
This PR has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 10 days. |
|
@TravisEz13 @IISResetMe apart from the merge conflict, was there anything else pending here? 💖 |
|
@vexx32 My comments have not been addressed. #8329 (review) |
The contexts in which this error string is used covers not only literals that are too large, but also sometimes too small Renamed to EnumeratorValueOutOfBounds
|
@TravisEz13 I believe the last two commits address your open comments :) |
|
@IISResetMe Please resolve merge conflicts. |
There was a problem hiding this comment.
Const should be upper case:
const TypeCode ValidUnderlyingTypeCodesThere was a problem hiding this comment.
Please add space after //:
| //no need to report error since there is error reported in method StatementRule | |
| // No need to report error since there is error reported in method StatementRule. |
|
@iSazonov done! |
|
The Codacy issue currently failing is not really relevant. While the compiler can't prove it, that path is unreachable since |
|
Yes, I see. I see that Codacy has many false-positives. |
|
@IISResetMe Thanks for your contribution! |
PR Summary
Fix #8028
This change adds support for specifiying the underlying type for an enum:
enum MyEnum : long { A = 0x0FFFFFFFFFFFFFFF B } # or enum MyByte : byte { A = 0x01 B = 0x02 C = 0x03 D }TODO:
currently breaks on negative value literals(fixed in 19b2770)value assignment is currently broken from non-int types(fixed in f58eba8)PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests