Fix Issues 19399 and 10560 - Different Conversion Rules for Same Value and Type Enum

[RazvanN7]

Once the enum value has been analyzed and lowered to a literal expression, if the enum type cannot be implicitly converted to the desired type, VRP steps in and does the appropriate type modifications; this is problematic because it bypasses the type that the user has provided. To fix this, I added a check that disables VRP if the user provided type cannot be implicitly converted to the desired type; if no type is provided for the enum, the initial behavior is still in place (i.e. [1]).

[1] https://issues.dlang.org/show_bug.cgi?id=9999

[dlang-bot]

Thanks for your pull request and interest in making D better, @RazvanN7! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	10560	critical	Enum typed as int with value equal to 0 or 1 prefer bool over int overload
✓	19399	critical	Different Conversion Rules for Same Value and Type -- Enum

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#10099"

[RazvanN7]

Phobos fix: dlang/phobos#7094

[thewilsonator]

This should target stable

[RazvanN7]

This cannot target stable. It is silent change of code behavior; I thought about issuing a deprecation, but deprecations are issued for errors.

[thewilsonator]

Fair enough.

[WalterBright]

Merge above two lines, no point to ed variable.

[WalterBright]

This introduces a very subtle bug. Take a look at the function getMemType(). If memtype is not provided, it is set to a default value. Now take a look at syntaxCopy(), which creates a new EnumDeclaration and passes memtype to it. But if memtype was set by getMemType(), it is not null, and hasUserDefinedType is incorrectly set to true.

The easiest way to fix this is have syntaxCopy() also copy hasUserDefinedType.

[WalterBright]

Or more properly, make hasUserDefinedType a parameter to the constructor.

[WalterBright]

The referenced issues are not compiler bugs and are not language bugs. See explanations added to https://issues.dlang.org/show_bug.cgi?id=19399