Have one source of truth for the language transitions

[wilzbach]

From Usage.transitions the following is generated:

• CLI parsing
• CLI help text
• man pages
• Future: dlang.org documentation

[dlang-bot]

Thanks for your pull request, @wilzbach!

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.

[wilzbach]

Look ma, this was already outdated.

[JinShil]

This is great stuff. But we need some way to verify it, and ensure it stays in tact. Adding a rendered man page to CyberShadow/DAutoTest would allow us to manually verify not only the man page generation, but also, because the man page is generated from all this logic, it would allow us to verify that logic as well. I'm just thinking out loud at the moment, maybe there is a more elegant way to test/verify the output.

[wilzbach]

This is great stuff. But we need some way to verify it, and ensure it stays in tact. Adding a rendered man page to CyberShadow/DAutoTest would allow us to manually verify not only the man page generation, but also, because the man page is generated from all this logic, it would allow us to verify that logic as well. I'm just thinking out loud at the moment, maybe there is a more elegant way to test/verify the output.

No this is a great idea: dlang/dlang.org#2067

[wilzbach]

Any idea why LDC 32-bit on Travis is failing?

Test failed.  The logged output:
../generated/linux/release/32/dmd -conf= -m32 -Irunnable -g  -odtest_results/runnable -oftest_results/runnable/gdb10311_0 runnable/gdb10311.d
gdb test_results/runnable/gdb10311_0 --batch -x test_results/runnable/gdb10311_0.gdb
Breakpoint 1 at 0x8048632: file runnable/gdb10311.d, line 19.
test_results/runnable/gdb10311_0.gdb:3: Error in sourced command file:
During startup program exited normally.
==============================
Test failed: 
GDB regex: 'RESULT=.*33' didn't match output:
----
Breakpoint 1 at 0x8048632: file runnable/gdb10311.d, line 19.
test_results/runnable/gdb10311_0.gdb:3: Error in sourced command file:
During startup program exited normally.
----
make[1]: *** [test_results/runnable/gdb10311.d.out] Error 1
make: *** [start_runnable_tests] Error 2
make: *** Waiting for unfinished jobs....

This looks pretty unrelated as it Semaphore with LDC 64-bit does pass.

[wilzbach]

This looks pretty unrelated as it Semaphore with LDC 64-bit does pass.

Yeah it's happening here too: https://travis-ci.org/dlang/dmd/jobs/326928291

Do we really need to test building DMD with LDC x86 as bootstrap compiler? Isn't 32-bit on the way out anyways and any sane porter will use LDC x86_64 for cross compilation or bootstrapping from LDC LTS?
CC @klickverbot @kinke

[kinke]

So DMD compiled with LDC fails that gdb test? Sounds pretty odd.
There's no 32-bit LDC for Linux and OSX anymore (just for Windows). From the Travis log:

$ $DC --version
LDC - the LLVM D compiler (1.7.0):
  based on DMD v2.077.1 and LLVM 5.0.1
  built with LDC - the LLVM D compiler (1.7.0)
  Default target: x86_64-unknown-linux-gnu

[wilzbach]

So DMD compiled with LDC fails that gdb test? Sounds pretty odd.

Yep, it might it have something to do with Travis. Their performance and reliability decreased in the last weeks.

There's no 32-bit LDC for Linux and OSX anymore (just for Windows).

Oh sorry for the confusion. I was trying to say using LDC to build DMD 32-bit on Linux.
So you guys would be okay with only doing LDC 64-bit -> DMD 64-bit bootstrapping builds?
-> #7653

[dnadlinger]

There's no 32-bit LDC for Linux and OSX anymore (just for Windows).

That's not true, by the way; I'm sure some distros (Debian/…) are packaging it on x86 as well.

[dnadlinger]

Not sure whether papering over the issue without trying to reproduce it first is a good idea; it might of course be a codegen bug in LDC, but it might also be indicative of a bug in DMD (e.g. undefined behaviour due to invalid memory accesses, which just so happens not to cause any issues during normal operation).

[kinke]

That's not true, by the way

[I was referring to the official packages as used by Travis.]

it might of course be a codegen bug in LDC

In a DMD PR I opened shortly after this, that test was failing on Travis with dmd host compiler as well.

[wilzbach]

In a DMD PR I opened shortly after this, that test was failing on Travis with dmd host compiler as well.

Yeah it looks like it was one of those spurious failures.

but it might also be indicative of a bug in DMD (e.g. undefined behaviour due to invalid memory accesses, which just so happens not to cause any issues during normal operation).

Bootstrapping with DMD is among other tested with 32_32, 32_64, 64_32 and 64_64 on auto-tester with 2.068.2 and with 64_32 on SemaphoreCI.
My question was whether there's any use case in which one would want to bootstrap DMD x64_32 from LDC on Linux and can't bootstrap x64_64 directly.