[nuclide-swift] Support Linux

[modocache]

Issue and Steps to Reproduce

Originally reported by @zxw454034941.

1. Install Nuclide and the language-swift package in an Ubuntu 14 environment
2. Build SourceKitten on Linux via the instructions in [WIP] Linux Support jpsim/SourceKitten#223.
3. Set the path to the SourceKitten executable to the build product from step 2
4. Build a Swift package via the toolbar
5. Open a Swift file in the package and begin typing

Expected Behavior

Autocompletion works, just as it would on macOS.

Actual Behavior

Autocompletion results from SourceKit do not appear.

Versions

• Atom: v1.9.9
• Nuclide: v0.165.0
• Client OS: Ubuntu 14
• Server OS (optional):

---

I think any official announcement of Linux support in nuclide-swift can wait until after jpsim/SourceKitten#223 is merged, but it would be nice to investigate what the issue is here beforehand.

[drgmr]

SourceKitten is now somewhat compatible with Linux considering the instructions on their README. Also, jpsim/SourceKitten#223 was closed in favor of jpsim/SourceKitten#268

I've had limited success running a Docker image based on norionomura/sourcekit:30 image in an Arch host and editing this line to allow SourceKitten execution on non-Darwin platforms. The autocomplete seems to be not so responsive and limited to Foundation or current file types, ignoring any imports from SPM dependencies, which I'm not sure if it's a nuclide-swift or SourceKitten issue to be honest since it could be related to the current "partial" requirement of a Swift 3 toolchain on SourceKitten's master.

Versions:

• Atom: v1.12.2
• Nuclide: v0.177.0
• Client OS: Dockerized Ubuntu 14.04 on 4.7.1-1-ARCH host

[modocache]

Awesome, thanks for trying it out! One thing to note: autocompletion requires you to first build the Swift package via the task runner toolbar (see the docs; sorry I'd link them but I'm on a plane and the WiFi is super slow). Are you saying that autocompletion is limited to just the current file on Linux, even though it works well when you try it on macOS?

[drgmr]

Yeah, I did build it a few times using the toolbar, making changes and seeing if the autocomplete would report them properly. I can't really try it on a macOS machine right now and didn't use nuclide for swift development on a mac when I could - what I said about it being limited is mostly based on what I expected from such a functionality, e.g., pressing ctrl+space on a Vapor 1.1 Droplet instance gives me no suggestions (sometimes only ones that where already used, but I think that's Atom's "dumb" autocomplete, not related to nuclide).

[modocache]

Hmm... I don't have any ideas off the top of my head. If you have some time to plug away at it, maybe try to diagnose the issue, that'd be awesome. Otherwise hang tight, I'll try to get to it soon.

[nzatsepilov]

Recently I tried to test autocompletion on linux with latest sourcekitten. Still not work (I followed the steps above, removed check for non-darwin systems and compiled code before testing).
I didn't have any error notifications in atom, so there were no issues with calling sourcekitten. Then tried to debug it here. Exit code was 0 with stderror:
<unknown>:0: error: unable to load standard library for target 'x86_64-unknown-linux-gnu
But SourceKitten worked properly via command line: completion.json
I couldn't find anything how to solve this issue, I guess it can be related with my OS.

• Atom: v1.12.2
• Nuclide: v0.177.0
• OS: Ubuntu 14.04
• SourceKitten: 9ede44
• Swift: 3.0.1 release with SourceKit

[modocache]

That's strange. The error message you're seeing is coming from the Swift compiler. I would certainly expect this error message to be the same regardless of whether you invoke sourcekitten via the command line, or via Nuclide.

The nuclide-swift packages passes an additional set of compiler flags to SourceKitten here. It looks like those flags may be causing the Swift compiler to produce that error. That's strange, since the commands should be the exact ones included in the YAML file SwiftPM produces.

The best way to diagnose the issue would be to add a console.log to your Nuclide installation on the line that I linked to above. Take a look at the compiler arguments being passed to SourceKitten. If you invoke SourceKitten yourself with those same arguments, does it produce an error? If so, check the YAML file SwiftPM produces (I believe it's called debug.yaml or release.yaml. Do the compiler arguments in that file work? If not, perhaps this is an issue with SwiftPM.

[nzatsepilov]

Did more tests yesterday. Found location where sourcekitten works properly. Issue was related with libraries of sourcekit.
Autocompletion doesn't appear correctly for instance methods:
let a = []
a. doesn't appear
a.a appear
Kind source.lang.swift.decl.function.method.instance exists in sourcekitten's result. It's stdout logged by atom's dev console when I tried to complete a.

[modocache]

Issue was related with libraries of sourcekit.

So it was an issue with SourceKit and SourceKitten? Is there an issue on the SourceKitten repository, or a Swift JIRA bug report that explains what the issue was? I'm curious to see if I can help. :)

[nzatsepilov]

As you could understand sourcekit, sourcekitten were builded using docker, link. Norio Nomura has implemented custom build for sourcekit (link) in on linux, which not contains in main swift repo.
In the end we have only builded sourcekitten, some of dependencies were in docker containers. So I needed to solve problems with some of it:

• error while loading shared libraries: libswiftCore.so: cannot open shared object file: No such file or directory
  It was solved by additional library path in .bashrc: export LD_LIBRARY_PATH="$SWIFTENV_ROOT/versions/3.0.1-RELEASE/usr/lib/swift/linux:$LD_LIBRARY_PATH" (i'm using swiftenv, $SWIFTENV_ROOT located in ~/,switenv
• <unknown>:0: error: unable to load standard library for target 'x86_64-unknown-linux-gnu'
  I didn't find exact reason. But I think this error related with dynamic linking for stdlib. Probably in my case missed dependency in libsourcekitdInProc.so or libswiftCore.so (link, link)
  Solved by adding in .bashrc:
  export LD_LIBRARY_PATH="/usr/include:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH"
export LINUX_SOURCEKIT_LIB_PATH="$SWIFTENV_ROOT/versions/3.0.1-RELEASE/usr/lib/libsourcekitdInProc.so"
  Also sourcekitten should be located near libsourcekitdInProc.so, in swift/usr/lib/. Now my current path to soucekitten is ~/swftenv/versions/3.0.1-RELEASE/usr/lib/sourcekitten. I don't know why but it works only here althought I added LINUX_SOURCEKIT_LIB_PATH env var and tried to move sourcekitten to /opt/sourcekitten/. Anyway I added link of sourcekitten to /ust/bin.

To use sourcekitten I needed launch atom using terminal (sourcekitten should use env vars for normal work).
It's all. You can correct me, some of this stuff I did first time or long time ago.
By the way, have you any plans to support swift modules or multiple files? For example I see we can't use completion in this case: use public/internal stuff from A.swift in B.swift. If yes how soon?

[modocache]

Thanks for the detailed report! It sounds like SourceKitten on Linux requires some additional environment variables to be set. Perhaps the best way forward is to provide Nuclide configuration options for those paths, so that users may set them to the correct paths and get SourceKitten working.

By the way, have you any plans to support swift modules or multiple files? For example I see we can't use completion in this case: use public/internal stuff from A.swift in B.swift.

This is definitely supported! I've only ever used nuclide-swift on macOS, and it can do autocompletion across files there. In fact, that's the main reason I built this package. :)

[nzatsepilov]

It's great. But it doesn't work for me.

[modocache]

Hmm... I assume you did, but just in case: did you build the package via the task runner toolbar after having added both main.swift and Robot.swift? The compile commands need to be updated any time the files change.

I'll try to take a closer look at this over the weekend.

[nzatsepilov]

Yes, I did.

[MatejLach]

Tested this myself, works on command line but not in the editor.
On macOS, it works as expected.

[viveksinghmehta]

Failed to load Sourcekit
Home/usr/swift/usr/lib/libsourcekitdInProc.so:libBlocksRuntime.so.0:cannot open shared object file:No such file or directory

[viveksinghmehta]

what to so

[viveksinghmehta]

do*