Refactor: Move resolvedLinkage from AST to Semantic layer

[Adityazzzzz]

This PR moves the resolvedLinkage logic from dmd.declaration.Declaration to dmd.dsymbolsem.
As part of the ongoing effort to separate semantic routines from AST nodes, resolvedLinkage was identified as an "intricate" dependency. While it appeared to be a simple property, it performed target-specific resolution (target.systemLinkage()), creating a semantic "leak" in the AST layer.

Changes

• declaration.d: Removed final LINK resolvedLinkage() from the Declaration class.
• dsymbolsem.d: Introduced a new semantic routine LINK resolvedLinkage(const scope Declaration d) to host the resolution logic.
• func.d: Updated isMain, isCMain, isWinMain, isDllMain, and isRtInit to use the new semantic routine.
• mangle/package.d & dtoh.d: Updated the mangler and header generator to call the semantic resolution instead of the AST property.
• glue/: Synchronized the backend glue code (toobj.d, tocsym.d, package.d) with the new architectural separation.

Impact
This change decouples the Declaration AST node from the target configuration and allows func.d to move closer to the "Done" list in the "Separate Semantic Routines" migration tracker.

[dlang-bot]

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

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

[Adityazzzzz]

@RazvanN7 I've started tackling the 'intricate solutions' for the Separate Semantic Routines project as part of my GSoC 2026 preparation.
This was one of the intricate cases involving backend interaction you mentioned in the project description. I'd appreciate any feedback on whether this provider-based approach aligns with the long-term architectural goals.

[ibuclaw]

Put this in cxxfrontend.d (and appropriate C++ header under the correct namespace). The top-level function in dsymbolsem should be extern(D).

[ibuclaw]

Also link test in compiler/src/tests

[ibuclaw]

All C++ consumers (gdc and ldc) should access exposed routines via the dmd namespace - for this, dmd::resolvedLinkage(d).

[ibuclaw]

On a little reflection, Is this is a good example to move? It doesn't do any semantic mutation on the decl. The main reason for splitting out methods from the tree.

[Adityazzzzz]

@ibuclaw thank you for the review,
Regarding your reflection on whether this is a good candidate: That is a very clarifying distinction. My initial thought process for moving it was to decouple the Declaration AST node from the global target state (target.systemLinkage()). However, I completely agree with your point that it doesn't perform any semantic mutation on the tree, which is the primary goal of the separation project.
I was trying to ensure I strictly align with the gsoc project's boundaries.

However, would you prefer I to?

• Implement your feedback here (moving the bindings to cxxfrontend.d, adding the dmd:: namespace, and writing the link test) just to practice the C++ interoperability workflow?
• Or, should I close this PR and pivot my focus to a function that performs actual semantic mutation (e.g., migrating a mutating pass from dstruct.d or dtemplate.d)?

Either way, your guidelines regarding cxxfrontend.d are incredibly valuable for mapping out.

[ibuclaw]

Have a look at the cxxfrontend module - what it's doing (its just a simple wrapper around extern(D) symbols), and run git blame on it to see what previous additions to it looked like.

[ibuclaw]

I think some easy examples to get started would be any of the extern (D) static member functions currently residing in AST node definitions. combine or extractLast?

[Adityazzzzz]

thank you @ibuclaw, I will look into how cxxfrontend.d wraps extern(D) symbols using git blame to understand the pattern.
I'll pivot away from resolvedLinkage and start working on extracting combine or extractLast as my starting point for the AST separation. I'll open a fresh PR for that once I have it mapped out