[maxches99]

Building swift-syntax with the MemberImportVisibility upcoming feature enabled currently fails: a number of files use declarations from modules that are only imported transitively — mostly the string-interpolation conformances from SwiftSyntaxBuilder and the indentation helpers from SwiftBasicFormat.

This PR adds the missing direct imports so that

swift build --build-tests -Xswiftc -enable-upcoming-feature -Xswiftc MemberImportVisibility

builds cleanly. All changes are plain import additions, with two exceptions:

• SwiftSyntaxMacroExpansion used SwiftBasicFormat without declaring it in Package.swift (the module was only available transitively; its CMakeLists.txt already links it), so the dependency is now declared.
• The existing import SwiftBasicFormat in MacroExpansion.swift becomes internal import to avoid an "ambiguous implicit access level for import" error once other files in the module import it as internal.

No CMakeLists.txt changes are needed — all affected modules already link the corresponding libraries.

The full test suite passes with the feature enabled, and swift format lint is clean on the touched files. A possible follow-up would be to enable the feature in Package.swift so new violations can't creep in.

Fixes #3301

[hamishknight]

Thanks!

A possible follow-up would be to enable the feature in Package.swift so new violations can't creep in.

I think we should do that in this PR to ensure we don't regress

[maxches99]

Done — enabled it for all regular and test targets in Package.swift. Older toolchains that don't know the upcoming feature ignore the flag, so this shouldn't affect them.

[hamishknight]

Thanks! Can you also update CMakeLists.txt to match? (sorry I should have mentioned this in my original comment)

[hamishknight]

I don't think we need to be this restrictive on the target kind, let's do type != .plugin instead, matching what we do for sourcekit-lsp (https://github.com/swiftlang/sourcekit-lsp/blob/a31d272f3cb392b443f42e1f97042a2a607073ec/Package.swift#L706)

[maxches99]

Done — switched to type != .plugin and added the flag to CMakeLists.txt. Verified the CMake build locally with the feature enabled.

[maxches99]

@hamishknight ping — this has been idle for three weeks. Both follow-ups from your review are in: the feature is enabled for every non-plugin target in Package.swift, and the same flag is set in CMakeLists.txt.

I've rebased this onto current main and rebuilt with the feature on. swift build --build-tests is clean — including the six files added under SwiftLexicalLookup since this PR went up, none of which needed a new import. But this is the kind of change that decays while it waits: every file added to main is one that might need an import, and the moment one does, the diff has to be regenerated and re-verified.

There are six reviewers assigned here, which I suspect is why nobody has picked it up. Could one of you take it, or reassign to whoever owns this area? CI also hasn't run on this PR at all — if someone can approve the workflows, that would cover the Linux, Windows and wasm builds I have no way to check locally.

[rintaro]

@swift-ci Please test

[maxches99]

Sorry for the long silence, and thanks for kicking off CI. The failure was on my side: PartialTypeResolutionTests.swift landed on main after my last rebase and relies on DeclSyntax(stringLiteral:) from SwiftSyntaxBuilder without importing it, which MemberImportVisibility now rejects.

I've rebased onto current main (on top of #3476, so the imports now go into the single access-level import block) and added the missing import SwiftSyntaxBuilder there and in four other test files that needed it. With the feature enabled, swift build --build-tests and the full swift test pass locally on Swift 6.3.

Could you please run @swift-ci please test again?