Skip to content

🍒 [6.2] [SourceKit] Support location info for macro-expanded Clang imports #82171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: release/6.2
Choose a base branch
from

Conversation

j-hui
Copy link
Contributor

@j-hui j-hui commented Jun 11, 2025

Explanation: Currently, when we jump-to-definition for decls that are macro-expanded from Clang imported decls, setLocationInfo() gives a file that does not exist. This patch fixes that by embedding the correct destination's ClangNode in the GeneratedSourceInfo, and using that.

Issues: rdar://151020332

Original PR: #82006

Risk: low

Testing: added regression test

Reviewers: @bnbarham @hnrklssn

@j-hui j-hui changed the title [SourceKit] Support location info for macro-expanded Clang imports 🍒 [6.2] [SourceKit] Support location info for macro-expanded Clang imports Jun 11, 2025
@j-hui
Copy link
Contributor Author

j-hui commented Jun 11, 2025

@swift-ci please test

@j-hui
Copy link
Contributor Author

j-hui commented Jun 11, 2025

@swift-ci please test macos platform

@j-hui j-hui marked this pull request as ready for review June 11, 2025 18:45
@j-hui j-hui requested a review from a team as a code owner June 11, 2025 18:45
Currently, when we jump-to-definition for decls that are macro-expanded
from Clang imported decls (e.g., safe overloads generated by
@_SwiftifyImport), setLocationInfo() emits a bongus location pointing to
a generated buffer, leading the IDE to try to jump to a file that does
not exist.

The root cause here is that setLocationInfo() calls getOriginalRange()
(earlier, getOriginalLocation()), which was not written to account for
such cases where a macro is generated from another generated buffer
whose kind is 'AttributeFromClang'.

This patch fixes setLocationInfo() with some refactoring:

-   getOriginalRange() is inlined into setLocationInfo(), so that the
    generated buffer-handling logic is localized to that function. This
    includes how it handles buffers generated for ReplacedFunctionBody.

-   getOriginalLocation() is used in a couple of other places that only
    care about macros expanded from the same buffer (so other generated
    buffers not not relevant). This "macro-chasing" logic is simplified
    and moved from ModuleDecl::getOriginalRange() to a free-standing
    function, getMacroUnexpandedRange() (there is no reason for it to be
    a method of ModuleDecl).

-   GeneratedSourceInfo now carries an extra ClangNode field, which is
    populated by getClangSwiftAttrSourceFile() when constructing
    a generated buffer for an 'AttributeFromClang'. This could probably
    be union'ed with one or more of the other fields in the future.

rdar://151020332
(cherry picked from commit 44aba13)
@j-hui j-hui force-pushed the j-hui/6.2/jump-to-def-for-macro-expanded-clang-imports branch from 0987033 to c94955b Compare June 13, 2025 01:24
@j-hui
Copy link
Contributor Author

j-hui commented Jun 13, 2025

@swift-ci please test

@j-hui j-hui enabled auto-merge June 13, 2025 01:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants