Package.swift support

[aaroncrespo]

Yeah, this is probably a big one. But its not 100% accurate to say that all swift files in a directory are part of or should provide completion data. A Package.swift( and xcodeproj....👻 ) is the mechanism for that..

[RLovelett]

I think it'd be smart for us to investigate how @modocache implemented this for nuclide-swift.

After #14 this is my next priority.

[aaroncrespo]

What kind of inline hinted are you thinking of?

[RLovelett]

Are you asking where would the information come from our what would the information look like in VS Code?

[aaroncrespo]

Hmm I guess the editor doesn't need to support package.swift to compile

[RLovelett]

I'm trying to ascertain that information myself currently. I would love it if SourceKit provided the information somewhere. That way it would be nice and parseable. (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.

EDIT: I've re-read what you wrote and I think the answer I gave you was non-sensical. I was responding to #14 and #17 at the same time.

It would be great to do 2 things regarding Package.swift SwiftPM integration.

1. Use SwiftPM to determine the appropriate compiler args to send to SourceKit.
2. Provide built in tasks to compile a package, release, debug, and test, directly in VS Code.

[aaroncrespo]

yeah for #14, maybe we can start with just plain old swift build and map the results to diagnostic objects.

As for this issue I did some setup https://github.com/RLovelett/vscode-swift/commits/swift-pm this brings a yaml parser, and typings for it.

Also swapped to the typings tool to mange typescript typings. How long ago was the project generated? tsd as a means to manage typed binding was deprecated (in favor of typings) but I saw that that's what was there.

A few weeks ago I created the template with yo and it came with typings pre integrated.

[RLovelett]

I think the build YAML that you that is going to build off of is only created after running swift build right?

Off-topic: I created the project on July 27 using yo. If the typings and/or config are out-of-date with the state-of-the-art I'm fine with changing it. The only thing I'd ask is: can you just do it as a stand-alone house keeping/chore PR? I am still new to the Typescript thing and seeing the change as a stand-alone will help me understand what is actually going on with this thing. (Trying to learn)

[aaroncrespo]

Only reason I saw that was because I was looking into how to add the typings via tds and saw the big deprecated warning. There's was a migration tool in typings so I just ran that.

[aaroncrespo]

if I recall when I cloned the deck of cards project, and run swift build it fetches what was in Packages.swift and built the project. There was also yaml info

[modocache]

Just chiming in with a silly idea: there's a naive solution here, one that doesn't involve any sort of integration with SwiftPM:

1. By default SwiftPM leaves build products in /path/to/your/package/root/.build. Find a debug.yaml or release.yaml files in that directory.
2. Choose the newer of any YAML files found.
3. Parse the compile commands in that file.

This won't work if the .build directory doesn't exist at the default path (either because SwiftPM hasn't built the project yet, or because the user specified a --build-path argument when building), but you might find it good enough for now...?

I think integrating with swift build is ideal in the long run, though. For nuclide-swift, for example, I'd like to regenerate the compile commands periodically, by having swift build run in the background from time to time, generating build products in a hidden, Nuclide-specific directory. That way, the user won't need to manually rebuild the project to get up-to-date autocompletion results.

[aaroncrespo]

Yeah something like that was going to be the first step. Supporting tooling around Package.swift is a side effect of first being able to parse and use the YAML it outputs. And then exposing a friendlier editor UI around swift build.

Maybe an inaccurate issue title.

P.S. Feature Idea: Neat thing about language servers, is we could even provide specialized completions for Package.swift files. Not sure what that would look like yet, the precedent exists throughout VSCode already though: auto completion for all the various settings in configs.

[RLovelett]

This is now implemented in the latest version of the language server. See RLovelett/langserver-swift@32356cf.