Remove TypeInfo.init

[aG0aep6G]

as planned

[dlang-bot]

Fix	Bugzilla	Description
✓	12233	Attempting to use TypeInfo.init results in a compiler error due to lack of 'this'.

[schveiguy]

LGTM. Not sure how the changelog works, but I wouldn't have expected you to have to delete the old changelog entry.

[schveiguy]

Looks like TypeInfo.init is used in some DMD tests, so those have to be updated to use initializer before this will pass.

[wilzbach]

Not sure how the changelog works, but I wouldn't have expected you to have to delete the old changelog entry.

Yeah ideally all changelog should be removed with every new major release..

[aG0aep6G]

Looks like TypeInfo.init is used in some DMD tests, so those have to be updated to use initializer before this will pass.

The only failure I can find in the logs is this:

Test failed: 
expected:
----
fail_compilation/ice15441.d(24): Error: variable ice15441.main.__front62 type void is inferred from initializer __r61.front(), and variables cannot be of type void
fail_compilation/ice15441.d(24): Error: expression __r61.front() is void and has no value
fail_compilation/ice15441.d(24): Error: s1.front is void and has no value
fail_compilation/ice15441.d(27): Error: cannot infer argument types, expected 1 argument, not 2
----
actual:
----
fail_compilation/ice15441.d(24): Error: variable ice15441.main.__front63 type void is inferred from initializer __r62.front(), and variables cannot be of type void
fail_compilation/ice15441.d(24): Error: expression __r62.front() is void and has no value
fail_compilation/ice15441.d(24): Error: s1.front is void and has no value
fail_compilation/ice15441.d(27): Error: cannot infer argument types, expected 1 argument, not 2
----

fail_compilation/ice15441.d doesn't seem to do anything with TypeInfo.init. The unexpected output is off only in some generated numbers. Could this be because I've added a unittest to object.d? If so, how do I proceed here? Make a PR for dmd that bumps those numbers?

---

Yeah ideally all changelog should be removed with every new major release..

That should have happened when 2.074 was branched off, right? Looks like it was overlooked. To be clear, I'm aiming for 2.075 here.

[schveiguy]

how do I proceed here?

Hm... that seems kind of brittle. One thing we can do is move the unit test elsewhere, and then move it back when the fragility of the dmd tests can be addressed (create a bug report, I would say).

Another option is to move the unit test items into an already existing block, but I'm not 100% sure that will fix it, not sure what that numbering scheme comes from.

[aG0aep6G]

Turns out dmd's d_do_test has a mechanism to avoid hard-coding generated numbers in expected error messages. PR to use it: dlang/dmd#6684

[aG0aep6G]

Turns out dmd's d_do_test has a mechanism to avoid hard-coding generated numbers in expected error messages. PR to use it: dlang/dmd#6684

That PR has been merged. Auto-tester is turning green now.

[schveiguy]

Auto-tester is turning green now.

Nice!