-
Notifications
You must be signed in to change notification settings - Fork 7
Create language diagnostic support #14
Comments
I would love it if SourceKit provided the information somewhere. That way it would be nice and parseable. I'm trying to ascertain if SourceKit provides such an API. (Though if that is not possible then compilation is the only avenue left to us). From there it should merely be a process of converting the Swift diagnostic format to the VS Code Diagnostic format and sending it to the editor. |
🎉 Found it! It was already documented in Protocols.md. Source/// Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam ut nisi finibus, sodales risus
/// vel, hendrerit risus. Ut sed magna ultricies, congue odio commodo, posuere risus. Cum sociis
/// natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. In feugiat lacus
/// elementum, maximus quam quis, suscipit neque. Curabitur pretium efficitur felis sit amet
/// facilisis. Cras tincidunt pulvinar neque, eu varius sapien gravida quis. Suspendisse potenti.
struct Foo {
/// Cras tincidunt pulvinar neque, eu varius sapien gravida quis.
let bar: Int
/// Suspendisse potenti.
let baz: Bool
/// Cras tristique facilisis metus, ac bibendum lorem efficitur at. Vivamus finibus rhoncus
/// ipsum molestie convallis. Sed ac sem at nisl consectetur ornare. Aenean purus magna,
/// consequat id sodales sed, rhoncus eu augue. Lorem ipsum dolor sit amet, consectetur
/// adipiscing elit.
///
/// - parameter qux: Sed dapibus nisi at velit interdum, et.
init(qux: String) {
self.bar = 3
self.baz = false
}
}
ley Y = Food(qud: 3) For example, running a source file that looks like above through that SourceKit request returns: Request
ResponseSkip to
Now I need to implement it in node-sourcekit. |
Looks like this needs package.swift support so you can fill out the compiler args? |
Yes and no. There exists a functionality to get the compiler args for a given workspace. But what exists right now is not robust at all. It is merely a list of the files in the workspace (minus the file you are interrogating). I say all of that to say: not having SwiftPM/Package.swift support is not a blocker for this feature. And considering an interface is already in place to query for such information I would imagine whatever SwiftPM/Package.swift support was created in the future would simply provide the same interface and could easily be deprecate/replace this existing functionality. |
Yeah, I guess for a start using swift PM to get a list of files in the |
So the current status is that vscode-swift uses SourceKitten, but node-sourcekit will be a replacement at some point? Or is it used in some branch already? Inline errors would be awesome. :) From a normal IDE user's standpoint SourceKit crashes (or used to crash) a lot. I wonder if anybody's tried to write a more lightweight syntax checker simply on top of Swift's own Parser/Lexer, to catch and highlight errors that way. Of course the deeper code analysis could still happen via SourceKit. |
There is a limitation in vsode wrt to native plugin node modules. For now no node-sourcekit.
I haven't really seen many crashes in any swift writing I've done in the past year and a half.
Thats pretty much SourceKit. I don't know how you could get more light weight though. Swift type checking and resolution is very modern and not so simple. SourceKit is swifts paser/lexer. It generates the AST for the compiler. Writing that while keeping up with swift's evolution is already a challenge for sourcekit. |
@aaroncrespo is right there is an upstream issue with VS Code that is a blocker. At least for now in moving to node-sourcekit. See: microsoft/vscode#658 for more information. Because of that road-block I'm now looking at implementing the VS Code language server protocol natively in Swift. Very early days and don't really have anything to show yet but I think that would be cool to write the Swift language server...in Swift. SourceKit is OSS now. With that if we, the community, are experiencing crashes etc then I think the best course of action is to fix the problems there rather than make a fork or some new Parser/Lexer. Beyond that I have no interest in trying to keep up with parsing this language. 🙃 I actually think projects like this, that also stand on SourceKit, will help make SourceKit stable for everyone eventually. |
Thanks for the comments @aaroncrespo & @RLovelett ! Trying to wrap my head around all of this. And yeah, luckily SourceKit has been more stable recently :) I just had it crash on Friday for the first time in a long while and that sparked my comments. I bet it'll keep improving. Writing the language server in Swift definitely sounds like a good idea! I'll keep following the progress and help if I can. |
Inline errors etc.
The text was updated successfully, but these errors were encountered: