Fix Issue 13292 - DMD accepts both -m32 and -m64

[wolframw]

Now raises an error when conflicting -mXXX arguments are given.
However, multiple -mXXX are still valid, iff all XXX are the same.

[dlang-bot]

Thanks for your pull request and interest in making D better, @wolframw! 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
✓	13292	normal	DMD accepts both -m32 and -m64

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#11058"

[wolframw]

I did not expect destroying other tests with this change... I'll have a look on it later.

[MoonlightSentinel]

I don't think we should do this because it's pretty common to allow flags to override previous flags. E.g. gcc allows both -m32 -m64 and other dmd flags can be specified mutliple times as well (e.g. -checkaction=C -checkaction=context)

[MoonlightSentinel]

Not needed, every test in this test suite is compiled with -m${MODEL}

[MoonlightSentinel]

Avoid bash tests, either convert this into a dshell test or create fail_compilation/fail13292.d with an appropriate TEST_OUTPUT section, e.g.

/*
REQUIRED_ARGS: -m32 -m64
TEST_OUTPUT:
----
Error: Conflicting target architectures specified: $?:32mscoff=-m32mscoff and -m32|32=-m32 and -m64|64=-m64 and -m32$.
----
*/

[MoonlightSentinel]

I did not expect destroying other tests with this change... I'll have a look on it later.

E.g. compilable/b18197.d relies on the ability to override the target architecture (which defaults to the hosts) because the bug is -m32(mscoff) specific.

[wolframw]

I don't think we should do this because it's pretty common to allow flags to override previous flags. E.g. gcc allows both -m32 -m64 and other dmd flags can be specified mutliple times as well (e.g. -checkaction=C -checkaction=context)

Do you think it's better changing the error message to a warning or just scratching this whole thing?
(This issue is tagged "bootcamp", I sort of—perhaps naïvely so—assumed this to have a similar meaning to "preapproved".)

[MoonlightSentinel]

Do you think it's better changing the error message to a warning or just scratching this whole thing?

Personally the latter because current behaviour is pretty common but let's see what other people think.

(This issue is tagged "bootcamp", I sort of—perhaps naïvely so—assumed this to have a similar meaning to "preapproved".)

To quote the wiki:

The "bootcamp" bugs are manually earmarked by senior contributors as bugs that are fit for a beginner to tackle. The ideal bootcamp bug is easy but not too easy, has good impact, can be fixed in 1-3 days by a motivated beginner, and offers a good learning experience.

[wolframw]

"earmarked by senior contributors" and "has good impact" is exactly what makes me assume that the fix to such an issue has at least some value and will not end up in the bin (which is what I meant with "bootcamp" being similar to "preapproved").
Nonetheless, I now agree that this isn't a good idea. Any tests that have their own -m are pretty much unfixable, as far as I understand, which is in itself a good example why overriding the -m flag can be useful. Thanks for the helpful comments anyway.

[Geod24]

@wolframw : Thanks for tackling this, and sorry it didn't end up being something we can merge.
I incorporated the discussion in this PR in the issue and marked it as WONTFIX.

For reference, anyone can do triage on Bugzilla, so we might have slightly different interpretation of what it means depending on when the label was applied / who applied it. I just did a quick search and some of those issues are definitely not trivial and require deep understanding of how things work, while some other seem much simpler.