Skip to content

[SourceKit] Stop using isSystemModule to represent "non-user" modules #64367

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

Merged
merged 1 commit into from
Mar 17, 2023

Conversation

bnbarham
Copy link
Contributor

Rather than using ModuleDecl::isSystemModule() to determine whether a module is not a user module, instead check whether the module was defined adjacent to the compiler or if it's part of the SDK.

If no SDK path was given, then isSystemModule is still used as a fallback.

Resolves rdar://89253201.

@bnbarham
Copy link
Contributor Author

@swift-ci please test

Rather than using `ModuleDecl::isSystemModule()` to determine whether a
module is not a user module, instead check whether the module was
defined adjacent to the compiler or if it's part of the SDK.

If no SDK path was given, then `isSystemModule` is still used as a
fallback.

Resolves rdar://89253201.
@bnbarham
Copy link
Contributor Author

@swift-ci please test

@@ -32,11 +32,10 @@ import CxxStdlib
import CxxModule

// REMARK_NEW: remark: emitting symbolic interface at {{.*}}/interfaces/std-{{.*}}.pcm.symbolicswiftinterface{{$}}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hyp I'm somewhat confused as to the cause of this failure. It seems like CxxShims is now getting a symbolic interface in this test, which changes the order of the output (though I couldn't reproduce it locally which is odd). I imagine we must now be indexing something where we weren't before and that ends up including CxxShims?

But IIRC what we really care about here is that CxxModule + std are emitted and that we don't emit them when the PCM isn't updated. So I've updated the test to reflect that.

For reference, the failing output was:

        16: <unknown>:0: remark: indexing system module at BUILD_DIR/lib/swift/macosx/Cxx.swiftmodule/x86_64-apple-macos.private.swiftinterface 
        17: <unknown>:0: remark: emitting symbolic interface at BUILD_DIR/test-macosx-x86_64/Interop/Cxx/symbolic-imports/Output/indexing-emit-libcxx-symbolic-module-interface.swift.tmp/store/interfaces/CxxShim-G46YUHGO4LYP.pcm.symbolicswiftinterface; skipping because it's up to date 
        18: <unknown>:0: remark: emitting symbolic interface at BUILD_DIR/test-macosx-x86_64/Interop/Cxx/symbolic-imports/Output/indexing-emit-libcxx-symbolic-module-interface.swift.tmp/store/interfaces/CxxShim-G46YUHGO4LYP.pcm.symbolicswiftinterface; skipping because it's up to date 
        19: <unknown>:0: remark: emitting symbolic interface at BUILD_DIR/test-macosx-x86_64/Interop/Cxx/symbolic-imports/Output/indexing-emit-libcxx-symbolic-module-interface.swift.tmp/store/interfaces/std-THR17V9MOTXM.pcm.symbolicswiftinterface 
        20: <unknown>:0: remark: emitting symbolic interface at BUILD_DIR/test-macosx-x86_64/Interop/Cxx/symbolic-imports/Output/indexing-emit-libcxx-symbolic-module-interface.swift.tmp/store/interfaces/std-THR17V9MOTXM.pcm.symbolicswiftinterface; skipping because it's up to date 
        21: <unknown>:0: remark: emitting symbolic interface at BUILD_DIR/test-macosx-x86_64/Interop/Cxx/symbolic-imports/Output/indexing-emit-libcxx-symbolic-module-interface.swift.tmp/store/interfaces/CxxModule-1OH37PNV2MYG1.pcm.symbolicswiftinterface 
next:35
        22: EOF 

@bnbarham
Copy link
Contributor Author

@swift-ci please test

Copy link
Contributor

@xymus xymus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I may be able to reuse this non-user concept for another concern, to ignore distributed adjacent swiftmodules for distributed modules.

@bnbarham
Copy link
Contributor Author

Looks good! I may be able to reuse this non-user concept for another concern, to ignore distributed adjacent swiftmodules for distributed modules.

Do you think it's worth using "distributed" here instead of "non-user" 🤔?

@bnbarham bnbarham merged commit fd84ae9 into swiftlang:main Mar 17, 2023
@bnbarham bnbarham deleted the system-to-sdk branch March 17, 2023 17:15
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.

4 participants