statement_toIR(): simplify conversion of label statements to goto

[WalterBright]

by not needing another hash table

[dlang-bot]

Thanks for your pull request, @WalterBright!

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 fetch digger
dub run digger -- build "master + dmd#10323"

[WalterBright]

@TurkeyMan @CyberShadow

The buildkite/dmd error:

../../crypto/vibe/crypto/cryptorand.d(173,6): Error: cannot modify `const` expression `p`

The code https://github.com/vibe-d/vibe.d/blob/master/crypto/vibe/crypto/cryptorand.d

auto p = atomicLoad(*cast(const shared GET_RANDOM*) &hasGetRandom);
if (p == GET_RANDOM.UNINITIALIZED)
{
	p = initHasGetRandom() ? GET_RANDOM.AVAILABLE   <= error on this line
					: GET_RANDOM.NOT_AVAILABLE;

Perhaps it has something to do with this? dlang/druntime#2739

[WalterBright]

Looks like the buildkite/dmd error is unrelated to this PR.

[ibuclaw]

Same as #10322, I'd like a small pause for thought before going ahead. As I've said in the other, this reverts #4854, and goes against the reasoning for using a hash table in the first place - to remove dmd backend-only fields from common frontend types.

If the reasoning for this is the same as in #10322, then perhaps it would be better to jump straight to something that uses the frontend for data analysis, rather than a halfway solution that has no effect for either gdc/ldc, other than slightly increasing memory usage.

[CyberShadow]

Looks like the buildkite/dmd error is unrelated to this PR.

It was the breaking change in dlang/druntime#2739. @thewilsonator force-merged it.

[WalterBright]

then perhaps it would be better to jump straight to something that uses the frontend for data analysis

Because it took several tries for me to get this correct (making stupid mistakes). Getting it right here, where there is plenty of code to exercise all the cases, is a heluva lot easier than looking for subtle bugs in DFA, which is notoriously hard to debug.

other than slightly increasing memory usage

It's actually less memory usage, because the hash table with the same number of values (and hence quadruple the storage because of the key, hash, and link) is no longer needed.