Fix bugzilla issue 24153 - Inliner breaks -betterC by requiring TypeInfo

[bangbangsheshotmedown]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @bangbangsheshotmedown! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	24153	blocker	Inliner breaks -betterC by requiring TypeInfo

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#17049"

[thewilsonator]

This otherwise looks good. If you consider this issue to be a blocker, you might want to rebase to target stable instead of master.

[bangbangsheshotmedown]

This otherwise looks good. If you consider this issue to be a blocker, you might want to rebase to target stable instead of master.

I don't know how to do that, the command fails: fatal: Does not point to a valid commit 'upstream/stable'

[thewilsonator]

For a small PR like this it's probably easier to just recreate it locally on stable and then and open a new PR. Saves messing around with git. Just make sure to select stable when choosing with branch to target.

[bangbangsheshotmedown]

For a small PR like this it's probably easier to just recreate it locally on stable and then and open a new PR. Saves messing around with git. Just make sure to select stable when choosing with branch to target.

Do you think it is worth it? I checked stable and that code lives in a different file, I feel like it'll cause some issues when merging later?

[thewilsonator]

If you are fine waiting a while for it to get into a release then you don't need to. Do you want me to merge this as is now?

[bangbangsheshotmedown]

If you are fine waiting a while for it to get into a release then you don't need to. Do you want me to merge this as is now?

I use LDC for release build, so it doesn't really impact me, I guess you can merge it as is