Issue Description:

Stable release of Swift 2.2 came with repl missing module warning.

When try to access Swift repl it shows me the following output

http://hastebin.com/obihaxujep.rb

is blocked by:

• SR-1300 LLDB REPL tests fail on Ubuntu when not run from install layout

Issue Description:

duplicates:

• SR-77 In the repl, auto-indent overwrites text

Issue Description:

I am creating a switch statement in REPL. Whenever I add the necessary colons at the end of the case keyword, the value I want for the case disappears.

This code

switch letters {
    default
}

becomes

switch letters {
    def:
}

whenever I tried to add the colon.
Somehow, the case statements are being concatenated when I add the colon.

Issue Description:

On OS X, 4 LLDB Go-related unit tests are failing. These do not fail on same toolchain on llvm.org.

These are:
FAIL: test_go_formatter_plugin (lang/go/formatters/TestGoFormatters.py)
FAIL: test_goroutine_plugin (lang/go/goroutines/TestGoroutines.py)
FAIL: test_with_dsym_and_python_api_dsym (lang/go/expressions/TestExpressions.py)
FAIL: test_with_dsym_and_python_api_dwarf (lang/go/expressions/TestExpressions.py)

$ go version
go version go1.5.2 darwin/amd64

Attachment: Download

blocks:

• SR-843 TestREPLDictionary.py failing (pexpect error timeout) on Ubuntu

is duplicated by:

• SR-1301 PR Linux bot always fails LLDB lots of REPL tests

relates to:

• SR-2136 LLDB asserting on missing glibc module: Ubuntu, master-next, build layout only

Issue Description:

The LLDB REPL tests fail when the LLDB is used out of the build/ directory from the Ubuntu packager CI here:

• https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/

• https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/

Those tests pass if run from the install image layout of LLDB (in the package /usr/bin/lldb from the same build).

Issue Description:

See build breakage here:
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/945/console

Swift LLDB builds using builders that do not have swig, and thus use the static swig bindings baked into the build, will fail on non-Apple OSes.

This is due to early evaluation of some new Apple-specific #ifdef code that is happening at swig file generation time instead of at the "compile in the generated binding" code. The net effect is that all systems using the static swig bindings are getting the #ifdef APPLE code erroneously.

In the case of Ubuntu, this is causing the swig binding code to be using some Apple-specific constants and file handling.

This showed up now because this is the first time we've added #ifdef code to the swig Python type maps file.

Issue Description:

Add OS X LLDB build support for Release with Debug Info plus asserts, as occurs with:
swift/utils/build-script -l -r

Issue Description:

This needs to be investigated. I cannot repro it on external public systems. It may be related to the version of Xcode being used. I need to get finer-level detail out of the logs than shows up in the console.

duplicates:

• SR-1300 LLDB REPL tests fail on Ubuntu when not run from install layout

Issue Description:

https://ci.swift.org/job/swift-PR-Linux/

Build 1209 was the last successful build on the PR Linux bot.

These REPL tests are failing:

```
ERROR: testREPL (repl/quicklookobject/TestREPLQuickLookObject.py)
ERROR: testREPL (repl/recursive_class/TestREPLRecursiveClass.py)
ERROR: testREPL (repl/basic/TestREPLBasic.py)
ERROR: testREPL (repl/classes/TestREPLClasses.py)
ERROR: testREPL (repl/dyntype/TestREPLDynamicType.py)
ERROR: testREPL (repl/array/TestREPLArray.py)
ERROR: testREPL (repl/pounwrapping/TestPOUnwrapping.py)
ERROR: testREPL (repl/lazy_reverse/TestLazyReverse.py)
ERROR: testREPL (repl/type_lookup/TestREPLTypeLookup.py)
ERROR: testREPL (repl/func_definition/TestREPLFunctionDefinition.py)
ERROR: testREPL (repl/multilevelarrays/TestMultilevelArrays.py)
ERROR: testREPL (repl/subclassing/TestREPLSubclassing.py)
ERROR: testREPL (repl/closures/TestREPLClosure.py)
ERROR: testREPL (repl/structs/TestREPLStructs.py)
ERROR: testREPL (repl/po_repl_type/TestREPLPOReplType.py)
```

Attachment: Download

Issue Description:

Reproducing steps:

1. Install swift-2.2-SNAPSHOT-2015-12-22-a-osx.pkg
2. Install swift-2.2-SNAPSHOT-2015-12-22-a-osx-symbols.pkg
3. Run `sudo codesign -f --deep -s "Developer ID Application: Norio Nomura" /Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-22-a.xctoolchain`
4. Run `echo "settings set target.source-map /Users/buildnode/jenkins/workspace/oss-swift-package-osx /path/to/SWIFT_SOURCE_ROOT"> ~/.lldbinit`
5. Run `yes|xcrun launch-with-toolchain /Library/Developer/Toolchains/swift-latest.xctoolchain`
6. Extract attached lldb-test.zip and open lldb-test.xcodeproj by Xcode
7. Select Product>Run menu
8. Hit the breakpoint at `Swift.print`
9. Show `Variables View` cause the crash

Issue Description:

I install dependencies, download and install the last development snapshot of Swift. I can build packages and run "swift --version" but if I just try to run "swift" I get this error.

==5515==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

I have a docker container available for testing with if you need it.

Issue Description:

While in the Swift REPL defining a struct and creating a new value the evaluation of the value results in an error.

1> struct Point {
2.    var x: Float, y: Float 
3.    var d: Float { return y - x } 
4. }
5> var p = Point(x: -2.0, y: 3.0)
p: Point = error: summary string parsing error
6> print(p)
Point(x: -2.0, y: 3.0)

is duplicated by:

• SR-147 REPL crash on Linux

Issue Description:

in REPL:
for c in "hello".<TAB>
causes a crash

Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 408d205). Type :help for assistance.
1> for c in "hello".lldb: /home/ngupta/src/swift/swift/lib/Sema/TypeCheckConstraints.cpp:1246: Optional<swift::Type> swift::TypeChecker::getTypeOfExpressionWithoutApplying(swift::Expr *&, swift::DeclContext *, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener *): Assertion `exprType && !exprType->is<ErrorType>() && "erroneous solution?"' failed.
Aborted (core dumped)

Issue Description:

The TestBitfields.BitfieldsTestCase.test_and_python_api LLDB test started failing on swift-lldb/master when swift-llvm/stable and swift-clang/stable were updated last night.

Issue Description:

when building on Fedora Linux as:
utils/build-script --preset=buildbot_linux_1510 installable_package=/tmp/swift.tar.gz install_destdir=/tmp/swift-install

build fails at lldb install step:

===
CMake Error at scripts/cmake_install.cmake:36 (file):
file INSTALL cannot find

"/scratch/src/swift/build/buildbot_linux/lldb-linux-x86_64/lib/python2.7".
Call Stack (most recent call first):
cmake_install.cmake:42 (include)

FAILED: cd /scratch/src/swift/build/buildbot_linux/lldb-linux-x86_64 && /usr/bin/cmake -P cmake_install.cmake
ninja: build stopped: subcommand failed.
utils/build-script: command terminated with a non-zero exit status 1, aborting
utils/build-script: command terminated with a non-zero exit status 1, aborting

This is most probably due to this bug:
https://llvm.org/bugs/show_bug.cgi?id=25134

for which this is the patch:
https://github.com/tfiala/lldb/commit/20f3e63c2b1e2046e9b7175ec58435e566a07180

EDIT: this patch is already in swift's lldb, so there is some other issue here.

Attachment: Download

Issue Description:

On my system both python-3.4 and python-2.7 are installed.
swift-lldb selects the wrong version (3.4):

...
[6/840] Building CXX object scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o
FAILED: /usr/local/bin/clang++   -DHAVE_PROCESS_VM_READV -DHAVE_ROUND -DLIBXML2_DEFINED -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Dreadline_EXPOR
TS -Iscripts/Python/modules/readline -I/var/tmp/lldb/scripts/Python/modules/readline -I/var/tmp/lldb/include -Iinclude -I/var/tmp/build/Ninja-ReleaseAssert/llvm-linux-x86_64/
include -I/var/tmp/build/Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/include -I/var/tmp/llvm/include -I/var/tmp/llvm/tools/clang/include -I/var/tmp/build/Ninja-ReleaseA
ssert/swift-linux-x86_64/include -I/var/tmp/swift/include -I/var/tmp/lldb/source -I/usr/include/python3.4 -I/var/tmp/lldb/tools/clang/include -I../clang/include -I/usr/includ
e/libxml2 -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-dep
recated-register -Wno-vla-extension  -fno-exceptions -fno-rtti -Wno-macro-redefined -O3 -DNDEBUG -fPIC -MMD -MT scripts/Python/modules/readline/CMakeFiles/readline.dir/readli
ne.cpp.o -MF scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o.d -o scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o -c /var/tmp/ll
db/scripts/Python/modules/readline/readline.cpp
/var/tmp/lldb/scripts/Python/modules/readline/readline.cpp:68:34: error: assigning to 'char *(*)(FILE *, FILE *, const char *)' (aka 'char *(*)(_IO_FILE *, _IO_FILE *, const 
char *)') from incompatible type 'char *(FILE *, FILE *, char *)' (aka 'char *(_IO_FILE *, _IO_FILE *, char *)'): type mismatch at 3rd parameter ('const char *' vs 'char *')
    PyOS_ReadlineFunctionPointer = simple_readline;
                                 ^ ~~~~~~~~~~~~~~~
/var/tmp/lldb/scripts/Python/modules/readline/readline.cpp:70:5: error: use of undeclared identifier 'Py_InitModule4'
    Py_InitModule4(
    ^
2 errors generated.

Issue Description:

https://twitter.com/an0/status/681152454361128962

Having 'po' print an integer literal as an integer is nice and orthogonal, but also totally useless. It would be nice to preserve the ObjC behavior of treating the integer like an object reference and attempting to debugPrint the object.

Attachment: Download

Issue Description:

Receiving a crash in the REPL when executing the command:

:command history

See attached crash report

Issue Description:

It has been discovered that the compiler/debugger doesn't warn for certain things.

Also, a structural change needs to happen. Several issues arise when trying to separate methods from their respective wrapper files.

See the slew of messages over compiling Cairo on the mailing lists. This could be sooooooooo much simpler than it is right now, please improve drastically from what it is right now if possible.

Issue Description:

I am not sure exactly what is broken here, but something about the '--rerun-all-issues' and the rerun logic to clear test issues has broken. I've seen several builds where the errant test timed out and was rerun, the rerun succeeds, and then the test suite fails.

I suspect something changed upstream and this breakage came in when I brought in LLVM.org LLDB svn trunk through r265422 into GitHub swift-lldb.

This is high priority as it is causing builds to be flagged as failing when we don't intend it.

Issue Description:

let hex = "DEADBEEF"
let num = Int(hex, radix: 16)
guard let num = num else {
    fatalError("Couldn't parse \(hex) as an integer")
}

pasting the above program into the REPL, then adding print(num) prints Optional(3735928559). When I compile and run it, I get 3735928559.

Issue Description:

This test is failing on Ubuntu 15.10 on swift-master with recent changes from swift/swift-llvm/swift-clang.

FAIL: test_dwarf (functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py)
FAIL: test_dwo (functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py)

Issue Description:

This test started failing on OS X after last night's updates:

TestSwiftCrossModuleExtension.TestSwiftCrossModuleExtension.test_cross_module_extension

File "/Users/buildnode/jenkins/workspace/oss-lldb-incremental-osx/lldb/third_party/Python/module/unittest2/unittest2/case.py", line 391, in runMethod
testMethod()
File "/Users/buildnode/jenkins/workspace/oss-lldb-incremental-osx/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1476, in dwarf_test_method
return attrvalue(self)
File "/Users/buildnode/jenkins/workspace/oss-lldb-incremental-osx/lldb/packages/Python/lldbsuite/test/decorators.py", line 121, in wrapper
func(*args, **kwargs)
File "/Users/buildnode/jenkins/workspace/oss-lldb-incremental-osx/lldb/packages/Python/lldbsuite/test/lang/swift/cross_module_extension/TestSwiftCrossModuleExtension.py", line 42, in test_cross_module_extension
self.do_test()
File "/Users/buildnode/jenkins/workspace/oss-lldb-incremental-osx/lldb/packages/Python/lldbsuite/test/lang/swift/cross_module_extension/TestSwiftCrossModuleExtension.py", line 86, in do_test
lldbutil.check_variable(self,child_v,False,value="1")
File "/Users/buildnode/jenkins/workspace/oss-lldb-incremental-osx/lldb/packages/Python/lldbsuite/test/lldbutil.py", line 974, in check_variable
test.assertTrue(valobj.GetValue() == value, "expected value: '%s' - actual value: '%s'" % (value,valobj.GetValue() if valobj else "<unknown>"))
File "/Users/buildnode/jenkins/workspace/oss-lldb-incremental-osx/lldb/third_party/Python/module/unittest2/unittest2/case.py", line 462, in assertTrue
raise self.failureException(msg)

Issue Description:

When asking for a backtrace from lldb during an XCTest run, I get the weird print in the title.

1. Compile an XCTest target with e.g. SwiftPM. Or any method, really.
2. Run the compiled target with lldb:

lldb path/to/xctesttarget
(lldb) r

3. Convince lldb to stop during a test (by the test invoking fatalError or similar)
4. Ask for a backtrace:

(lldb) bt
GetSwiftTypeInfo() on non-legal SIL type not special cased. Name: (Swift.String, () throws -> ()) - Kind: 12
GetSwiftTypeInfo() on non-legal SIL type not special cased. Name: (Swift.String, () throws -> ()) - Kind: 12
GetSwiftTypeInfo() on non-legal SIL type not special cased. Name: (Swift.String, () throws -> ()) - Kind: 12
GetSwiftTypeInfo() on non-legal SIL type not special cased. Name: (Swift.String, () throws -> ()) - Kind: 12
GetSwiftTypeInfo() on non-legal SIL type not special cased. Name: (Swift.String, () throws -> ()) - Kind: 12
GetSwiftTypeInfo() on non-legal SIL type not special cased. Name: (Swift.String, () throws -> ()) - Kind: 12

Anecdotally, this behavior seems correlated with lldb segfaulting occasionally. Not sure if related.

Issue Description:

Looks like a simple missing import in some python module:

ERROR: test_attach_to_process_by_id_denied_dwo (TestAttachDenied.AttachDeniedTestCase)
Test attach by process id denied

Traceback (most recent call last):
File "/home/buildnode/jenkins/workspace/oss-lldb-incremental-linux-ubuntu-14_04/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1480, in dwo_test_method
return attrvalue(self)
File "/home/buildnode/jenkins/workspace/oss-lldb-incremental-linux-ubuntu-14_04/lldb/packages/Python/lldbsuite/test/decorators.py", line 123, in wrapper
func(*args, **kwargs)
File "/home/buildnode/jenkins/workspace/oss-lldb-incremental-linux-ubuntu-14_04/lldb/packages/Python/lldbsuite/test/functionalities/process_attach/attach_denied/TestAttachDenied.py", line 38, in test_attach_to_process_by_id_denied
pid = lldbutil.wait_for_file_on_target(self, pid_file_path)
File "/home/buildnode/jenkins/workspace/oss-lldb-incremental-linux-ubuntu-14_04/lldb/packages/Python/lldbsuite/test/lldbutil.py", line 1064, in wait_for_file_on_target
time.sleep(pow(2, i) * 0.25)
NameError: global name 'time' is not defined
Config=x86_64-/usr/lib/llvm-3.6/bin/clang

Attachment: Download

relates to:

• SR-1109 Cannot run swift REPL in 2016-03-24-a on Ubuntu 15.10. Missing SwiftGlibc?

Issue Description:

The first build of LLDB via the build steps used by the Ubuntu 15.10 builder will make it through fine. But, if something about any of the build steps fails after the initial lldb build (e.g. missing a package needed in some other part of swift that shows up after the lldb build), then lldb will go through its build steps again. During the rebuild using the packaging flow, lldb will fail to install with a message like this:

CMake Error at scripts/Python/modules/readline/cmake_install.cmake:44 (file):
file INSTALL cannot find
"/home/tfiala/src/lldb-github/build/buildbot_linux/lldb-linux-x86_64/scripts/Python/modules/readline/CMakeFiles/CMakeRelink.dir/readline.so".
Call Stack (most recent call first):
scripts/Python/modules/cmake_install.cmake:37 (include)
scripts/cmake_install.cmake:41 (include)
cmake_install.cmake:42 (include)

Inspection of the related directory tree shows there is no CMakeRelink.dir file:

$ find /home/tfiala/src/lldb-github/build/buildbot_linux/lldb-linux-x86_64/scripts/Python/modules/readline/CMakeFiles
/home/tfiala/src/lldb-github/build/buildbot_linux/lldb-linux-x86_64/scripts/Python/modules/readline/CMakeFiles
/home/tfiala/src/lldb-github/build/buildbot_linux/lldb-linux-x86_64/scripts/Python/modules/readline/CMakeFiles/readline.dir
/home/tfiala/src/lldb-github/build/buildbot_linux/lldb-linux-x86_64/scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o

Googling around seems to indicate that relink dir shows up when doing cross compiles, which I don't think should be taking place here. This might be related to the same change that is breaking SR-1109, as it did some changing around of host vs. target details.

Note I only hit this on a rebuild of lldb. (I get a very similar result if llbuild has to rebuild and reinstall).

relates to:

• SR-1109 Cannot run swift REPL in 2016-03-24-a on Ubuntu 15.10. Missing SwiftGlibc?

Issue Description:

SR-1109 showed up because the packaging integration tests were missing pexpect. However, LLDB's test suite on Ubuntu should have been trying to import Foundation or Glibc. Determine why those LLDB tests suite tests do not fail on Ubuntu while the end-to-end packaging tests do fail.

I suspect we'll find one of the following:

• LLDB REPL tests doing 'import Foundation' are skipped if not Darwin.

• LLDB REPL tests work in the lldb build tree on Ubuntu and only fail as a result of the packaging setup. This would generate another investigation.

Issue Description:

Many of the Swift-specific LLDB tests fail when building Swift LLDB on OS X after a deleted build dir using this build command:
swift/utils/build-script -l -r --no-assertions

Ran 525 test suites (87 failed) (16.571429%)
Ran 980 test cases (139 failed) (14.183673%)
Failing Tests (87)
FAIL: LLDB (suite) :: TestBulkyEnumsVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestCGImportedTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestEnumVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestExpressionAccessControl.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestExpressionErrors.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestExpressionScopes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestFilePrivate.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestFunctionVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestInOutVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestIndirectEnumVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestMultiOptionals.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestMultilangFormatterCategories.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestNSError.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSBValueUpdates.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSimpleExpressions.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSubmoduleImport.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftAnyObjectType.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftAnyType.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftArchetypeResolution.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftArrayType.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftAtObjCIvars.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftBacktracePrinting.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftBridgedArray.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftBridgedMetatype.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftBridgedStringVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftClassEmpty.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftClassStatic.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftClassTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftConditionalBreakpoint.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftDictionaryNSObjectAnyObject.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftDifferentClangFlags.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftDynamicValue.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftErrorType.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftExpressionsInClassFunctions.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftExpressionsInMethodsFromObjc.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftExpressionsInMethodsPureSwift.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGenericExpressions.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGenericExtension.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGenericSelf.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGenericTupleLabels.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGenericTypeOfNestedArchetype.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGenericTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGenericsResolution.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGetValueAsUnsigned.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftGlobals.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftHideRuntimeSupport.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftInstancePointerSetSP.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftLetInt.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftLocalClosureTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftLocalTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftMetadataSymbols.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftMetadataSymbolsType.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftMetatype.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftMultipayloadEnum.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftMultipleBases.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftNSArrayCodeRunningFormatter.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftNestedArray.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftObjCOptionals.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftOneCaseEnum.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftOptionSetType.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftOptionals.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPORecursiveBehavior.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPORefTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPOSysTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPOValTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPartiallyGenericFuncClass.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPartiallyGenericFuncContinuation.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPartiallyGenericFuncStruct.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftPrivateSelf.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftProtocolTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftRangeTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftReferenceStorageTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftStaticStringVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftStdlibDictionary.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftStdlibSet.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftStepping.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftStringVariables.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftStructChangeRerun.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftStructInit.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftTaggedPointer.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftTupleTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftTypeAliasFormatters.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftTypeLookup.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftTypeMetadata.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftTypes.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftZeroSizeGenericSelf.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)
FAIL: LLDB (suite) :: TestSwiftieFormatting.py (Darwin warp.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 i386)

Issue Description:

Assertion failed: (DeclKind , function lookup, file /Users/tfiala/src/lldb-github/llvm/tools/clang/lib/AST/DeclBase.cpp, line 1374.

This has been happening on the pre-merge setup. I'm ensuring the OS X build is green before I commit the fixed up merge.

Issue Description:

Issue Description:

relates to:

• SR-1202 Use instructions on Swift.org Do Not Work for Debug-enabled Toolchain

Issue Description:

Seems it depends on LLDB.framework which is not there on OSX:

$ which lldb-mi
/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin/lldb-mi
$ lldb-mi --help
dyld: Library not loaded: @rpath/LLDB.framework/LLDB
  Referenced from: /Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin/lldb-mi
  Reason: image not found
Trace/BPT trap: 5
$

Issue Description:

This will show up as soon as the merge from llvm.org lldb svn trunk gets submitted. I have it marked XFAIL, using this bug number to track.

Issue Description:

ERROR: [EXCEPTIONAL EXIT 6 (SIGABRT)] test_expressions_in_class_functions_dwarf (lang/swift/expression/static/TestSwiftExpressionsInClassFunctions.py)

is duplicated by:

• SR-1138 Unsigned types display as signed in REPL (UInt8, UInt16, UInt32, UInt64)
• SR-1751 Debugger shows data not matching the type of a variable

Issue Description:

For all unsigned integer types, the max property has a value of -1 instead of a correct positive value. However, when try to print these values, the output IS correct.

For example, in Swift REPL, UInt8.max is evaluated to -1, but print(UInt8.max) will generate the correct output, 255. Same applies to all other unsigned integer types.

How to reproduce:
1, launch Swift REPL
2, type UInt8.max

Attachment: Download

Issue Description:

1'm positing a few bugs for redhat support issues, whilst it is not an official supported distro, there are only a couple of small blockers for easy integration

when building swift-lldb on redhat os's, the Python support code is placed in ./lib64 and not /lib

all other libs are placed in /lib

This appears to be an upstream lldb issue.

The only place which impacts swift is the building of the install package, which expects everything to be in ./lib, the symlinks inside /lib64/Python2.7 even reffer to the ./lib directory

There are several possible fixes for this

1. Get upstream to fix the lldb bug
2. Patch the lldb build script to copy or move the Python2.7 directory from ./lib64 to ./lib post build.
3. Patch the package install file builder to look in both locations ie ./lib64 after ./lib

Issue Description:

ERROR: [EXCEPTIONAL EXIT 6 (SIGABRT)] test_with_dwarf (lang/swift/partially_generic_func/class/TestSwiftPartiallyGenericFuncClass.py)

relates to:

• SR-1202 Use instructions on Swift.org Do Not Work for Debug-enabled Toolchain

Issue Description:

Issuing swift or swift -v

dyld: Library not loaded: @rpath/LLDB.framework/LLDB
Referenced from: /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-03-24-a.xctoolchain/usr/bin/lldb
Reason: image not found
Trace/BPT trap: 5

Issue Description:

test/lang/swift/stepping/TestSwiftStepping.py started to fail after we merged the swift-3-indexing model branch.

We made some API changes to the library according to SE-0065 "A New Model for Collections and Indices". The API changes were in Range and Collection.

Issue Description:

Upstream llvm.org Linux folks currently assume using gcc as a compiler is a sufficient guard against building on a Linux without libc\\. However, on Swift Ubuntu, we build on Linux with clang (rather than gcc) but don't have libc\\. So the "compiling with clang" skipUnless variant isn't sufficient. Also, it's not really checking the key piece: whether libc\\ is available.

duplicates:

• SR-1007 Unsigned integer types have incorrect max values

Issue Description:

When the REPL evaluates unsigned values, they display as if they were signed. print() shows the correct unsigned value however. Probably related to: https://bugs.swift.org/browse/SR-1007

Example:
1> var x: UInt8 = 150
x: UInt8 = -106
2> print❌
150
3> var y: UInt16 = 50000
y: UInt16 = -15536
4> var z: UInt32 = 3000000000
z: UInt32 = -1294967296

is blocked by:

• SR-1203 Swift interactive shell fail to load in Bash on Ubuntu on Windows

Issue Description:

On Ubuntu 15.10 when attempting to launch the REPL I get:

1. swift
   error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8

1. uname -a
   Linux 8389598ee941 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

1. swift -v
   Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f829)
   Target: x86_64-unknown-linux-gnu
   /opt/swift/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu15.10/usr/bin/lldb "--repl=-target x86_64-unknown-linux-gnu -disable-objc-interop -color-diagnostics"
   error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8

relates to:

• SR-10931 Optional initialization inconsistent between Optional vs T?

Issue Description:

String and Double optional values intialized to nil are getting POed as:

1> class Foo<T,U> {
var t: T?
var u: U?
init() { t = nil; u = nil }
init(_ x: T, _ y: U) { t = x; u = y }
};(Foo<String,Double>(),Foo<Double,String>(3.14,"hello"))
1> class Foo<T,U> {
2. var t: T?
3. var u: U?
4. init() { t = nil; u = nil }
5. init(_ x: T, _ y: U) { t = x; u = y }
6. };(Foo<String,Double>(),Foo<Double,String>(3.14,"hello"))
$R0: (Foo<String, Double>, Foo<Double, String>) = {
0 = {
t = ""
u = 0
}
1 = {
t = 3.1400000000000001
u = "hello"
}
}

Note the default initializer of the class instance should have had t and u print out as nil.

Issue Description:

Running the following:

swift/utils/build-script -r -l

will fail in a cryptic way during the lldb build phase. The underlying issue is that the default Xcode build configuration gets used when an unsupported configuration is specified, but the default configuration is not something that will ever build properly on a developer machine.

This was not caught since the lldb/scripts/build-swift-cmake.py script, which wraps build-script, only allows the valid Debug and Release options to be passed to build-script.

Workaround:
Limit builds to Debug or Release with no asserts when using '-l' to add Swift LLDB into the mix.

Attachment: Download

blocks:

• SR-54 Unable to launch REPL in restricted Docker container

Issue Description:

When trying to launch Swift interactive shell, bash prompts the following:
error: failed to launch REPL process: process launch failed: 'A' packet returned an error: -1

However, when trying to compile other .swift files, Swift works just fine.
This issue seem to relate to kernel level capabilities that are restricted in a sandboxed container.

Issue Description:

The merge from llvm.org lldb svn trunk is causing a test failure. I'm marking it XFAIL and tracking with this bug.

$ uname -a  # Arch Linux
Linux marten 4.2.5-1-ARCH #​1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux
$ swift --version
Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c)
Target: x86_64-unknown-linux-gnu
$ pacman -Qi ncurses5-compat-libs | head -n2         liz@marten:~/Code/advent/swift
Name           : ncurses5-compat-libs
Version        : 6.0-2
$ pacman -Qi libtcap | head -n2
error: package 'libtcap' was not found
$ pacman -Qi libtinfo | head -n2 
Name           : libtinfo
Version        : 6-7

is duplicated by:

• SR-130 Problem with the switch control structure in REPL

Issue Description:

The best example is the switch statement. Upon opening up the repl:

Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
  1> let veg = "celery"
veg: String = "celery"
  2> switch veg { 
  3.     case "cel:ry"

line three was typed as `case "celery":`, but the auto-un-indent didn't quite take. It actually deleted the last three characters, so the colon got stuck in the middle. Hitting enter we'll see that `ry"` are actually gone, and the terminal hasn't redrawn them:

  1> let veg = "test" 
veg: String = "test"
  2> switch veg {     
  3.     case "cel: 

Issue Description:

This bug tracks a failing test that will show up in an upcoming LLDB merge from llvm.org lldb svn trunk.

Attachment: Download

relates to:

• SR-1287 Ubuntu 15.10: lldb packaging setup fails to install on rebuild
• SR-1296 Ensure the packaging integration tests fail the build if the Python pexpect module is not preset
• SR-1295 Investigate why SR-1109 wasn't caught in the LLDB test suite on Ubuntu

Issue Description:

babt@Swift-TestVM:~$ swift
Welcome to Swift version 3.0-dev (LLVM b010debd0e, Clang 3e4d01d89b, Swift 7182c58). Type :help for assistance.
1> import Glibc
repl.swift:1:8: error: missing required module 'SwiftGlibc'
import Glibc
^

1> import Foundation
error: The AST context is in a fatal error state.
1> ^C
1>

Issue Description:

This change will be to the Swift build-script.

I'll add an option to specify the compiler to use, and default it to the in-tree just-built clang.

The actual change will be in the swift repo since that is where build-script lives, although this change is logically for LLDB.