ftime-trace: break up the template instance span into sub-phases

[suyashkumar102]

-ftime-trace output in perfetto and the sema1 template instance block was just one big blob with nothing inside it. makes it really hard to tell if the time is going into arg evaluation, overload resolution, expanding members, sema2 or sema3.

added spans for:

• semanticTiargs (arg semantic)
• findBestMatch (overload resolution)
• expandMembers (sema1 on members)
• semantic2 on the instance
• trySemantic3 on the instance

fixes #22711

[dlang-bot]

Thanks for your pull request and interest in making D better, @suyashkumar102! 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

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.

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

• In preparation for migrating from Bugzilla to GitHub Issues, the issue reference syntax has changed. Please add the word "Bugzilla" to issue references. For example, Fix Bugzilla Issue 12345 or Fix Bugzilla 12345.(Reminder: the edit needs to be done in the Git commit message, not the GitHub pull request.)

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#22825"

[suyashkumar102]

Tested locally on Windows — here's what the trace looks like in perfetto after this PR. The Sema1: Template Instance blocks now have visible sub-spans nested inside them. Before this, the entire semantic analysis block was flat with no sub-breakdown, making it impossible to attribute compile-time regressions to specific phases. The selected slice at the bottom confirms Sema1: Template Arg Semantic: Repeat!(float, 4) is showing correctly.

[dkorpel]

How were these spans chosen? It's important to weigh the added granularity vs. the added overhead. If a span is always a constant time, or always a fixed percentage of the parent span, then it would only make the flame chart larger without adding new information. If you could show how the spans vary in different scenarios, that would be great!

[suyashkumar102]

@dkorpel
The spans were chosen to line up with the main phases involved in template instantiation in the compiler — argument semantic, overload resolution, member expansion, and the semantic2/3 passes. The idea was to break the template instance into a small number of meaningful steps rather than adding very fine-grained instrumentation.

To check whether they actually add useful information, I tried two contrasting cases:

Scenario A — Overload-heavy (select!bool with multiple constrained candidates):

Template instance ≈ 643 µs

Overload resolution ≈ 609 µs (~95%)

Members negligible

Scenario B — Recursive template (Fib!10):

Template instance ≈ 3.3 ms

Members ≈ 3.25 ms (~98%)

Overload resolution negligible

So the dominant cost shifts depending on the pattern — overload resolution in one case, member expansion in the other. Without the sub-spans both would just appear as “template instantiation”, even though the underlying work is very different.

For granularity vs overhead, I tried to keep it at a level where each span corresponds to a distinct kind of work, rather than splitting things further. That keeps the trace readable while still making it possible to see where time is going. Also, this is only active with -ftime-trace, so it doesn’t affect normal compilation.

[thewilsonator]

please make Lerror nested function and then return Lerror();

[suyashkumar102]

@dkorpel just following up on PR #22825 — answered your question about the span selection with some benchmark data. Let me know if you'd like any changes.

[dkorpel]

Please check the documentation on how to structure changelog entries, and proof-read the text

[suyashkumar102]

Fixed, used the correct format from the README and matched the span names to the actual trace output