Skip to content
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

Report whether a target is part of the root package in the sourcekit-lsp API #7492

Merged
merged 1 commit into from May 1, 2024

Conversation

ahoppen
Copy link
Contributor

@ahoppen ahoppen commented Apr 24, 2024

This is used so we don’t search for tests in targets of package dependencies.

Companion of apple/sourcekit-lsp#1201

rdar://126965614

…lsp API

This is used so we don’t search for tests in targets of package dependencies.

rdar://126965614
@@ -22,31 +22,45 @@ import class Build.BuildPlan
import class Build.ClangTargetBuildDescription
import class Build.SwiftTargetBuildDescription
import struct PackageGraph.ResolvedModule
import struct PackageGraph.ModulesGraph
Copy link
Member

Choose a reason for hiding this comment

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

Is there a way to implement this with private import? All of the types above without private import should not leak outside of SourceKitLSPAPI and we should work on making this list smaller instead of adding more to it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I viewed it similarly to how we use ResolvedModule in the API as well.

I agree that we should not expose these types in SourceKitLSPAPI, but completely wrapping ModuleGraph will be a fairly significant undertaking (we use it in other places in SourceKit-LSP as well) and I think that should be done when we switch all of SourceKitLSP to only use the API module. Doing that for 6.0 is too much work and risk though, so I'd prefer to keep this as-is for now and schedule time for 6.1 to extend the SourceKitLSPAPI module so that we don't need to import any other modules. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

That's fair, although I would like ModulesGraph (and Resolved* types) to go through a significant refactoring for performance improvements in the near future, which very likely is going to be a breaking change. I'm not sure of the timeline yet, it might need to be included in 6.0 if we see performance regressing too much due to other changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's fair. If an abstraction layer for LSP falls out of that, that's great. Otherwise, I'm happy to assist with any changes that need to be done in SourceKit-LSP due to the refactoring.

@MaxDesiatov
Copy link
Member

@swift-ci test

@ahoppen
Copy link
Contributor Author

ahoppen commented Apr 24, 2024

apple/sourcekit-lsp#1201

@swift-ci Please test

@ahoppen
Copy link
Contributor Author

ahoppen commented Apr 24, 2024

apple/sourcekit-lsp#1201

@swift-ci Please test

@ahoppen ahoppen merged commit 9aa348e into apple:main May 1, 2024
5 checks passed
ahoppen added a commit that referenced this pull request May 3, 2024
- **Explanation**: Cherry-pick the following to PRs which are companions
of apple/sourcekit-lsp#1213
  - #7505
  - #7492
- **Scope**: CMake build and SourceKit-LSP API
- **Risk**: Low, the SourceKit-LSP API is only used by SourceKit-LSP and
the CMake build changes will all be caught at build-time
- **Testing**: n/a
- **Issue**: n/a
- **Reviewer**: @DougGregor and @MaxDesiatov on
#7505 and
#7492

---------

Co-authored-by: Ben Barham <[email protected]>
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.

None yet

2 participants