fix issue 18300: range error demangling long symbol

[rainers]

The range error occurs if the demangler happens to hit the length of the buffer (which is a multiple of 4000 by default) with the chunk it tries to write into the buffer.

I didn't add the test case to the unittests because it's a 17k string which seems excessive.

[dlang-bot]

Thanks for your pull request, @rainers!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	18208	major	demangle RangeError@src/core/demangle.d(230)
✓	18300	normal	core.demangle demangling of really long symbol fails

[Ingrater]

That was quick. Almost like you have seen it coming ;-). Thanks for the fix.

[wilzbach]

@rainers It would be great if you could add a test for it. D is trying to get more and more stable and every bug fixed shouldn't appear again. Thanks!

[rainers]

Adding the symbol from the test case to the unittests in core.demangle would increase the file size by about 30k, probably with a measurable impact on every import of core.demangle.
Maybe we should move the demangler tests into a separate file in the test folder...

[wilzbach]

Maybe we should move the demangler tests into a separate file in the test folder...

Oh, I thought that's already the case.

[rainers]

I added a unittest that triggers the problem with small symbols, too, by passing a small initial buffer (first range error with buffer size 4).

[wilzbach]

edit: added as unittest below

[rainers]

changed commit message to also reference https://issues.dlang.org/show_bug.cgi?id=18208, as 18300 turnedout to be a duplicate.

[timotheecour]

• FWIW fixes issue 18208 -- demangle RangeError@src/core/demangle.d(230) #2116 uses a single small-sh symbol to trigger the bug (and fix it), but 0..10_000 seems more systematic OTOH.
  I don't care which one gets merged though, but we should just go ahead and merge one

• I have found another bug, and another fix in https://github.com/dlang/druntime/pull/2117/files

• as mentioned in both of my PRs, we can trigger bugs more economically by passing in a small dst instead of the built-in dst which uses a large 4K size buffer (which makes bugs only appear for large symbols)

[rainers]

FWIW #2116 uses a single small-sh symbol to trigger the bug (and fix it), but 0..10_000 seems more systematic OTOH.

This PR also contains a test for a small symbol for a variety of initial buffer length.

as mentioned in both of my PRs, we can trigger bugs more economically by passing in a small dst instead of the built-in dst

Sounds good, especially in the case of the other "remove" bug. In issue 18300 the limit has to be hit exactly, which does not seem very probable to begin with (there are thousands of large symbols in the phobos unittests but none triggered the error).

[wilzbach]

OK, I added the unittest without changing the buffer size below and I think this rested in the PR queue way too long

[wilzbach]

In the interest of getting this in before 2.079, I rebased to stable and due to our CI crisis, I'm going to merge this now manually.