Bug 17308 – [TEST/PROCESS] Figure out a way to test assertions in DMD more broadly

The quality of assertions just seems to be going downhill post conversion to D. https://github.com/dlang/dmd/pull/6412 I squinted with mistrust at this line for a full 5 minutes. --- assert(cdto.sizeok == SIZEOKdone || !cdto.isBaseOf(cdto, null)) Assert that `cdto' has had it's size determined, or that `cdto' is *not* a base class of... itself? Hmmm... surely that would be identical to having. --- assert(cdto.sizeok == SIZEOKdone || true) Which is identical to having. --- assert(true); At which point, one begins to wonder what on earth is this doing here if it's a no-op. If beta releases are compiled with -release, IMO they shouldn't be, as lots of bugs are falling through the gaps. The frequency that I'm getting assertion failures in code backported from D is just unnerving. Some past examples include. Change: https://github.com/dlang/dmd/pull/5875 Asserts with: extern(C++, ...) void ice(); Change: https://github.com/dlang/dmd/pull/5972 Asserts with: struct BitRange { this(size_t) { } } Change: https://github.com/dlang/dmd/pull/6065 Asserts with: struct DSO { MG mg; } struct TDSO { int a; DSO* b; } All these examples are reasonably simple code tests, so can not imagine them *not* being caught by beta testers.

> Beta releases should not be built with -release Err, no, beta releases should be as close as possible to the final release. I've lost count of the number of times I shipped a broken build of some project only because the bug was not reproducible in the debug version. So, I'm pretty sure having different build flags for betas and releases a bad idea. Nightly builds are a different story and I think could be built with assertions. I'm closing this as WONTFIX as I'm pretty sure the issue as stated would be a bad idea, but please reopen if you can argument the opposite or can suggest some other actionable way to improve the situation.

(In reply to Vladimir Panteleev from comment #1) > > Beta releases should not be built with -release > > Err, no, beta releases should be as close as possible to the final release. > I've lost count of the number of times I shipped a broken build of some > project only because the bug was not reproducible in the debug version. So, > I'm pretty sure having different build flags for betas and releases a bad > idea. > > Nightly builds are a different story and I think could be built with > assertions. > > I'm closing this as WONTFIX as I'm pretty sure the issue as stated would be > a bad idea, but please reopen if you can argument the opposite or can > suggest some other actionable way to improve the situation. I feel inclined to re-open. But only because I'm constantly finding bugs in the compiler. The fact that I'm still using the C++ frontend just makes it that more evident. Here's another one: https://issues.dlang.org/show_bug.cgi?id=17492

I think this issue should be more about keeping asserts like DIP1006 suggested: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md See also: https://github.com/dlang/dmd/pull/6103

(In reply to Iain Buclaw from comment #2) > I feel inclined to re-open. But only because I'm constantly finding bugs in > the compiler. The fact that I'm still using the C++ frontend just makes it > that more evident. I suggest that you find another way to achieve this goal. Here are some ideas: - Run the test suite without -release, if it's not being run that way yet - Build nightlies without -release - If the performance impact isn't too bad, just ship the release versions of DMD without -release. As stated, for reasons explained above, this issue is a Really Bad Idea. We already have enough trouble with the default build flags not matching up with what's shipped (mainly fPIC-related).

(In reply to Iain Buclaw from comment #2) > I feel inclined to re-open. But only because I'm constantly finding bugs in > the compiler. The fact that I'm still using the C++ frontend just makes it > that more evident. (To clarify - the above does further support the problem, however it does nothing to defend the solution you're proposing and the problems it would bring. See my message above)

(Reopened and renamed as discussed above)

(In reply to Vladimir Panteleev from comment #4) > Here are some ideas: One more: Use a DMD built without -release for the project tester, so that we test "real-life code" from community projects, instead of just our minimized test suite.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19243 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB