Yes, this is clearly a bug. @davezarzycki are you going to work on this or you want us to take a look?
@swift-ci create

Comment by Jim Ingham (JIRA)

I think this is a general problem with the TOT swift REPL on Linux. OTOH, I have another report of a similar (but not identical) failure in the current TOT linux REPL, OTOH this construct works fine on both the lldb:stable/swift:master branches of lldb and the lldb:upstream-with-swift/swift:master-next branches of lldb.

For clarity: it seems like there are two bugs here. First, the "Couldn't lookup symbols" noise. And second, the SIGSEGV bug while creating an object with an optional unowned. I'd prefer that this bug be about the latter. Thanks!

As to task assignment, the REPL isn't on my critical path and therefore I don't foresee working on this in the short to medium term. Sorry. :-(

Comment by Jim Ingham (JIRA)

But again, neither of these bugs occur on the current TOT swift REPL on macOS. Both expressions run without error and give the expected results. My guess is this is more general (though recently introduced) badness in the Linux Swift REPL.

Interesting. I rarely test the Linux REPL, but anecdotally speaking, I think it has been broken for a long time. Then again, I never install the built product, and I build/test Swift with the ToT llvm+clang compiler, so maybe I've wandered deep in the weeds. I don't know if this information helps.

Comment by Jim Ingham (JIRA)

There are tests that test basic REPL behavior in the testsuite. We should make sure they are still running on Linux.

I'm afraid I really can't reproduce this on my Linux machine, David.

davide@rad:~/work/build/Ninja-ReleaseAssert/lldb-linux-x86_64/bin$ ./lldb --repl
Welcome to Swift version 4.2-dev (LLVM 748f9878c8, Clang 6c624d9bad, Swift 86c26a9e32). Type :help for assistance.
  1> class C { unowned var next : C? }
  2>  let c = C()
c: C = {
  next = nil
}

FWIW, this is my configuration:

uname:

 uname -a
Linux 4.4.0-45-generic #​66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"
NAME="Ubuntu"
VERSION="16.04.1 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.1 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

To the best of my understanding, you're building with Red hat, which isn't quite a supported (officially) system. Might I ask you to try with Ubuntu?

I don't have access to an Ubuntu machine. At this point, I'd wager that the issue is not the OS but that I prefer unified builds over the slow "build-script". Let's just close this. Does that work for you?

Confirmed. The LLDB test suite fails spectacularly with unified builds, but when I try a `build-script` build, only two LLDB tests fail (pull request pending). Let's close this.