Debug Azure

[MoonlightSentinel]

Notes, will probably change a lot:

• Powershell task goes into 'debug' mode for some errors which hangs the pipeline forever microsoft/azure-pipelines-tasks#12954 looks related

[dlang-bot]

Thanks for your pull request and interest in making D better, @MoonlightSentinel! 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

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

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

[ibuclaw]

Looks like this doesn't change anything. Pipelines have been running for an hour.

[MoonlightSentinel]

Another optlink bug

[ibuclaw]

Kill optlink? Seriously no modern compiler uses OMF these days.

[ibuclaw]

The regressing PR was found to be dlang/druntime#3511.

[WalterBright]

https://issues.dlang.org/show_bug.cgi?id=22109

[Geod24]

https://issues.dlang.org/show_bug.cgi?id=22109

OPTLINK issues should go to OPTLINK's repository: https://github.com/DigitalMars/optlink/issues

[DoctorNoobingstoneIPresume]

Kill optlink? Seriously no modern compiler uses OMF these days.

I believe this is too harsh and unmotivated -- and it should not matter what other toolchains do.

Why stop development of the OMF part just because of a bug (or ten bugs) ? They are going to be fixed and then we are going to be able to integrate the blocked/reverted changes -- they are not that important (at least mine), plus we have to give some time to the person(s) who are going to fix the bugs.

Building with multiple toolchains and multiple versions of a toolchain helps catch bugs. Okay, today it has actually done the opposite of helping because of a bug in one such version. But generally it is a good thing.

But if we apply the "Everybody uses COFF etc." argument, we end up supporting a monopoly (similar to Internet Explorer 20 years ago and now Chromium in browsers).

Ultimately, while optlink bugs are under treatment, we can allow merging with that check failing. It is better than throwing away OMF and optlink -- and just as easy, IMO.

[thewilsonator]

Why stop development of the OMF part just because of a bug (or ten bugs) ?

That is not the question. The question is why (re)start development? the last functional commit was in 2015.

They are going to be fixed

Are they? Of the three open PRs, two have been open 10 months, the other 8 years. And there are 16 open issues.

Building with multiple toolchains and multiple versions of a toolchain helps catch bugs.

Bugs specific to that toolchain that we have to work around.

Okay, today it has actually done the opposite of helping because of a bug in one such version. But generally it is a good thing.

Indeed. What you don't appreciate is the cost of maintenance and extra cost of development that comes with supporting abandonware toolchains. Also this is Annoying not only to the development of DMD, but also to the users of DMD that hit those bugs, and if your toolchain doesn't work, newcomers will likely find some other language to learn.

But if we apply the "Everybody uses COFF etc."

the point is not that "Everybody uses COFF", its that nobody (else) uses OMF. We don't get to benefit of having other people maintain the toolchain, like with LLVM, GCC etc.

[ibuclaw]

GCC - and I believe more broadly Binutils - has never supported OMF and Mingw works just to fine on XP IIUC, provided you get an old enough version, I guess.

The only time I've even seen a mention of adding OMF support was from the 16-bit i386 community (they are small but still exist). Never saw any push come to fruition.

[DoctorNoobingstoneIPresume]

GCC - and I believe more broadly Binutils - has never supported OMF and Mingw works just to fine on XP IIUC, provided you get an old enough version, I guess.

I confirm that MinGW works very well on Windows XP.

The only time I've even seen a mention of adding OMF support was from the 16-bit i386 community (they are small but still exist). Never saw any push come to fruition.

And my beloved Digital Mars C++ (for 32-bit Windows) (and possibly Embarcadero for 32-bit Windows). But I agree that many other people are not using it.

[DoctorNoobingstoneIPresume]

Why stop development of the OMF part just because of a bug (or ten bugs) ?

That is not the question. The question is why (re)start development? the last functional commit was in 2015.

They are going to be fixed

Are they? Of the three open PRs, two have been open 10 months, the other 8 years. And there are 16 open issues.

Building with multiple toolchains and multiple versions of a toolchain helps catch bugs.

Bugs specific to that toolchain that we have to work around.

Okay, today it has actually done the opposite of helping because of a bug in one such version. But generally it is a good thing.

Indeed. What you don't appreciate is the cost of maintenance and extra cost of development that comes with supporting abandonware toolchains. Also this is Annoying not only to the development of DMD, but also to the users of DMD that hit those bugs, and if your toolchain doesn't work, newcomers will likely find some other language to learn.

But if we apply the "Everybody uses COFF etc."

the point is not that "Everybody uses COFF", its that nobody (else) uses OMF. We don't get to benefit of having other people maintain the toolchain, like with LLVM, GCC etc.

I understand... :(

May I ask whether it is acceptable to leave DMC/OPTLINK/OMF support in Github checks and mark that check as optional (non-blocking-for-merging) and emit a message "Do not bother investigating this." ?

(Sorry for posting this question in two conversations.)