-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Public API for getting information about build targets #6763
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
Conversation
This will probably need some iteration to get the API right for what sourcekit-lsp needs. |
@swift-ci please smoke test |
@ahoppen Using TargetBuildDescription for plugins wasn’t really feasible because it is very much geared towards “real” targets. So I introduced a new protocol that the existing target build description types and a type geared towards plugins can call implement. We should probably also figure out a way for how to get the compiler arguments for manifest compilation into this, IIRC there's some ad-hoc way to handle them in sourcekit-lsp. |
Sources/Build/BuildDescription/PluginTargetBuildDescription.swift
Outdated
Show resolved
Hide resolved
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
I have started to use this in swiftlang/sourcekit-lsp#793 and so far I have identified two problems:
|
35358a1
to
609e2a4
Compare
Moved the code to a new module, haven't addressed any feedback yet. |
609e2a4
to
095e66b
Compare
@swift-ci please test |
@swift-ci please test windows |
¯\_(ツ)_/¯ |
@swift-ci please test windows |
1 similar comment
@swift-ci please test windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to also add a new tests target and cover the new API in this PR?
Yes, definitely. First trying to figure out the right shape and behavior for the API. |
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
I just updated swiftlang/sourcekit-lsp#793 to use the new API and the second issue I noted (about missing The following issue still exists, though
|
Looks like I was returning URLs for the file paths, I think that may have been the issue? |
Oh, also for plugins the file paths aren't returned at all, that is true. |
I made some more fixes here and this is mostly passing the existing sourcekit-lsp tests in
|
This is the patch I was working with on top of the sourcekit-lsp branch Alex created:
|
@swift-ci please test |
0754650
to
b4f2ecf
Compare
@swift-ci please test |
@swift-ci please test windows |
b4f2ecf
to
f8baf20
Compare
@swift-ci please test |
@swift-ci please test windows |
Ugh, I guess I'll have to change or split up |
Until now, SourceKit-LSP has been using a couple of internal data structures of the build plan, which were incidentally public, for this. This changes exposes a new public API for accessing information about build targets, including those for plugins. Note that this API is part of a new module which could be the start of a "proper" public API for SwiftPM. That said, right now it depends on several types of existing modules in its public interface and that isn't likely to be resolved as part of this particular change. rdar://112120976
f8baf20
to
ad4a08b
Compare
I don't really understand why I can't reproduce the failure locally, but it also seems like |
@swift-ci please test |
@swift-ci please test windows |
3 similar comments
@swift-ci please test windows |
@swift-ci please test windows |
@swift-ci please test windows |
Consistently seeing this again, I guess I'll wait a bit before retriggering Windows
|
@swift-ci please test windows |
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
This uses the new API in SwiftPM introduced by swiftlang/swift-package-manager#6763 to get compiler arguments for a target instead of stitching them together in sourcekit-lsp. Fixes swiftlang#664 rdar://102213837
Until now, SourceKit-LSP has been using a couple of internal data structures of the build plan, which were incidentally public, for this. This changes exposes a new public API for accessing information about build targets, including those for plugins.
Note that this API is part of a new module which could be the start of a "proper" public API for SwiftPM. That said, right now it depends on several types of existing modules in its public interface and that isn't likely to be resolved as part of this particular change.
rdar://112120976