apple/swift

The Swift Programming Language

Swift Programming Language

	Architecture	Build
macOS	x86_64
Ubuntu 18.04	x86_64
Ubuntu 20.04	x86_64
Ubuntu 20.04	AArch64
Ubuntu 22.04	x86_64
Ubuntu 22.04	AArch64
CentOS 7	x86_64
Amazon Linux 2	x86_64
Amazon Linux 2	AArch64
Universal Base Image 9	x86_64

Cross-Compilation Targets

Target	Build
wasm32-unknown-wasi

Swift Community-Hosted CI Platforms

OS	Architecture	Build
Android	ARMv7
Android	AArch64
Windows 2019 (VS 2019)	x86_64

Welcome to Swift

Swift is a high-performance system programming language. It has a clean and modern syntax, offers seamless access to existing C and Objective-C code and frameworks, and is memory-safe by default.

Although inspired by Objective-C and many other languages, Swift is not itself a C-derived language. As a complete and independent language, Swift packages core features like flow control, data structures, and functions, with high-level constructs like objects, protocols, closures, and generics. Swift embraces modules, eliminating the need for headers and the code duplication they entail.

To learn more about the programming language, visit swift.org.

• Contributing to Swift
• Getting Started
  • Swift Toolchains
  • Build Failures
• Learning More

Contributing to Swift

Contributions to Swift are welcomed and encouraged! Please see the Contributing to Swift guide.

To be a truly great community, Swift.org needs to welcome developers from all walks of life, with different backgrounds, and with a wide range of experience. A diverse and friendly community will have more great ideas, more unique perspectives, and produce more great code. We will work diligently to make the Swift community welcoming to everyone.

To give clarity of what is expected of our members, Swift has adopted the code of conduct defined by the Contributor Covenant. This document is used across many open source communities, and we think it articulates our values well. For more, see the Code of Conduct.

Getting Started

If you are interested in:

• Contributing fixes and features to the compiler: See our How to Submit Your First Pull Request guide.
• Building the compiler as a one-off: See our Getting Started guide.
• Building a toolchain as a one-off: Follow the Getting Started guide up until the "Building the project" section. After that, follow the instructions in the Swift Toolchains section below.

We also have an FAQ that answers common questions.

Swift Toolchains

Building

Swift toolchains are created using the script build-toolchain. This script is used by swift.org's CI to produce snapshots and can allow for one to locally reproduce such builds for development or distribution purposes. A typical invocation looks like the following:

  $ ./swift/utils/build-toolchain $BUNDLE_PREFIX

where $BUNDLE_PREFIX is a string that will be prepended to the build date to give the bundle identifier of the toolchain's Info.plist. For instance, if $BUNDLE_PREFIX was com.example, the toolchain produced will have the bundle identifier com.example.YYYYMMDD. It will be created in the directory you run the script with a filename of the form: swift-LOCAL-YYYY-MM-DD-a-osx.tar.gz.

Beyond building the toolchain, build-toolchain also supports the following (non-exhaustive) set of useful options:

• --dry-run: Perform a dry run build. This is off by default.
• --test: Test the toolchain after it has been compiled. This is off by default.
• --distcc: Use distcc to speed up the build by distributing the C++ part of the swift build. This is off by default.
• --sccache: Use sccache to speed up subsequent builds of the compiler by caching more C++ build artifacts. This is off by default.

More options may be added over time. Please pass --help to build-toolchain to see the full set of options.

Installing into Xcode

On macOS if one wants to install such a toolchain into Xcode:

1. Untar and copy the toolchain to one of /Library/Developer/Toolchains/ or ~/Library/Developer/Toolchains/. E.g.:

  $ sudo tar -xzf swift-LOCAL-YYYY-MM-DD-a-osx.tar.gz -C /
  $ tar -xzf swift-LOCAL-YYYY-MM-DD-a-osx.tar.gz -C ~/

The script also generates an archive containing debug symbols which can be installed over the main archive allowing symbolication of any compiler crashes.

  $ sudo tar -xzf swift-LOCAL-YYYY-MM-DD-a-osx-symbols.tar.gz -C /
  $ tar -xzf swift-LOCAL-YYYY-MM-DD-a-osx-symbols.tar.gz -C ~/

2. Specify the local toolchain for Xcode's use via Xcode->Toolchains.

Build Failures

Try the suggestions in Troubleshooting build issues.

Make sure you are using the correct release of Xcode.

If you have changed Xcode versions but still encounter errors that appear to be related to the Xcode version, try passing --clean to build-script.

When a new version of Xcode is released, you can update your build without recompiling the entire project by passing --reconfigure to build-script.

Learning More

Be sure to look at the documentation index for a bird's eye view of the available documentation. In particular, the documents titled Debugging the Swift Compiler and Continuous Integration for Swift are very helpful to understand before submitting your first PR.

swift's Issues

[SR-74] Passing reference of uninitialized lazy to C function leads to memory issues during deinit

Previous ID	SR-74
Radar	None
Original Reporter	etan (JIRA User)
Type	Bug

Attachment: Download

Environment

OS X 10.11.1 (15B42)
Xcode Version 7.1.1 (7B1005)
Swift version 2.1 (700.1.101.6 700.1.76)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 45a7d69794999ab90b93c6c258f5fb14

Issue Description:

To understand this issue, a C API is necessary with two C functions. One to store a function and an info pointer - a second one to call the stored function with the stored pointer as argument.

typedef void (* CFuncCallback)(void * info);
void CFuncStore(CFuncCallback callback, void * info);
void CFuncCall();

static CFuncCallback _callback;
static void * _info;

void CFuncStore(CFuncCallback callback, void * info) {
    _callback = callback;
    _info = info;
}

void CFuncCall() {
    if (_callback) {
        _callback(_info);
    }
}

A simple info object and C callback function are implemented in Swift to access this C API.

final class Info {
    init() { print("Info: init.") }
    deinit { print("Info: deinit.") }
}

func cCallback(info: UnsafeMutablePointer<Void>) {
    print("Callback from C.")
    print(UnsafePointer<Info>(info).memory)
    print("Test successful - no crash.")
}

Now, a Swift object is defined.

• On init(), an Info instance is created and registered with the C API.

• On deinit, invoke CFuncCall is invoked. This should be fine, as the Swift object still holds a reference to the info object while deinit is in progress.

final class SwiftObj {
    var info: Info = {
        print("SwiftObj: Alloc info.")
        return Info()
    }()

    init() {
        print("SwiftObj: init.")
        CFuncStore(cCallback, &info);
        print("SwiftObj: init done.")
    }
    
    deinit {
        print("SwiftObj: deinit.")
        CFuncCall()
        print("SwiftObj: deinit done.")
    }
}

An instance of SwiftObj is created and immediately destroyed, producing this log:

[SR-46] Documentation in PDF or HTML

Previous ID	SR-46
Radar	None
Original Reporter	bobblestiltskin (JIRA User)
Type	Improvement
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s
Labels	Improvement
Assignee	mattt (JIRA)
Priority	Medium

md5: 8758bb35ea991d740665a2a19d6da0a7

Issue Description:

The Swift Programming Language is the authoritative reference for Swift, offering a guided tour, a comprehensive guide, and a formal reference of the language. You can download the latest version below.

The Swift Programming Language (ePub)

Errr...

Please can we have this in PDF format or even old-skool HTML?? Please :-)

[SR-9] Activate enum import tests on Linux

Previous ID	SR-9
Radar	rdar://problem/20651533
Original Reporter	@jopamer
Type	Bug
Status	Reopened
Resolution

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	Bug
Assignee	King (JIRA)
Priority	Medium

md5: 18e965d66c831b43c6feca10c1b21c92

Issue Description:

Many of the Swift compiler tests in test/ClangModules that exercise enum import are broken on Linux and currently disabled there.

[SR-28] swiftc crashes on type equality check in where clause

Previous ID	SR-28
Radar	None
Original Reporter	tmandry (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Environment

OS X 10.11.1
Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift f44f4a5) - built 12/3/15

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: d7069ba447e02f44dc0f206de7bc11fb

Issue Description:

The following code causes the compiler to crash with an assertion failure. The compiler seems to be sensitive to the length of MyVeryLongAType. Specifically, renaming that to AType causes the code to compile. Removing the where clause also causes the code to compile.

protocol AProtocol {
}

protocol BProtocol {
  typealias MyVeryLongAType: AProtocol
  typealias MyOtherAType: AProtocol
}

class MyClass<BType: BProtocol where BType.MyVeryLongAType == BType.MyOtherAType> {
}

Here's the output:

Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift f44f4a5a35)
Target: x86_64-apple-macosx10.9
/Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift -frontend -c -primary-file main.swift -target x86_64-apple-macosx10.9 -enable-objc-interop -color-diagnostics -module-name main -o /var/folders/xl/kvdphsfj6230q3f8_m9h5zhw0000gn/T/main-f13ccf.o
Assertion failed: (NextValue < Values.size()), function claimNext, file /Users/tyler/code/swift/swift/lib/IRGen/Explosion.h, line 129.
0  swift                    0x0000000110cfccce llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1  swift                    0x0000000110cfd119 PrintStackTraceSignalHandler(void*) + 25
2  swift                    0x0000000110cf98b9 llvm::sys::RunSignalHandlers() + 425
3  swift                    0x0000000110cfd459 SignalHandler(int) + 345
4  libsystem_platform.dylib 0x00007fff91c5952a _sigtramp + 26
5  swift                    0x00000001117a0d3c cmark_strbuf__initbuf + 95547
6  swift                    0x0000000110cfd13b raise + 27
7  swift                    0x0000000110cfd1f2 abort + 18
8  swift                    0x0000000110cfd1d1 __assert_rtn + 129
9  swift                    0x000000010b924b31 swift::irgen::Explosion::claimNext() + 129
10 swift                    0x000000010b8de81b (anonymous namespace)::EmitPolymorphicParameters::emitWithSourcesBound(swift::irgen::Explosion&) + 683
11 swift                    0x000000010b8cdd52 (anonymous namespace)::EmitPolymorphicParameters::emitForGenericValueWitness(llvm::Value*) + 578
12 swift                    0x000000010b8cda5f swift::irgen::emitPolymorphicParametersForGenericValueWitness(swift::irgen::IRGenFunction&, swift::NominalTypeDecl*, llvm::Value*) + 95
13 swift                    0x000000010b8339cd swift::irgen::emitFieldTypeAccessor(swift::irgen::IRGenModule&, swift::NominalTypeDecl*, llvm::Function*, llvm::ArrayRef<swift::irgen::FieldTypeInfo>) + 1437
14 swift                    0x000000010b7e3069 swift::irgen::IRGenModuleDispatcher::emitLazyDefinitions() + 553
15 swift                    0x000000010b92e93c performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, swift::SourceFile*, unsigned int) + 1388
16 swift                    0x000000010b92f0d7 swift::performIRGeneration(swift::IRGenOptions&, swift::SourceFile&, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, unsigned int) + 167
17 swift                    0x000000010b638b48 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&) + 18728
18 swift                    0x000000010b63394c frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 12812
19 swift                    0x000000010b61adad main + 4285
20 libdyld.dylib            0x00007fff8b08f5ad start + 1
Stack dump:
0.  Program arguments: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift -frontend -c -primary-file main.swift -target x86_64-apple-macosx10.9 -enable-objc-interop -color-diagnostics -module-name main -o /var/folders/xl/kvdphsfj6230q3f8_m9h5zhw0000gn/T/main-f13ccf.o
<unknown>:0: error: unable to execute command: Illegal instruction: 4
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)

[SR-3] #if doesn't allow newlines

Previous ID	SR-3
Radar	rdar://problem/21292236
Original Reporter	@jopamer
Type	Bug
Status	Closed
Resolution	Won't Do

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, StarterBug
Assignee	None
Priority	Medium

md5: b0022cbdfcd07a37c2c13d958c707445

Issue Description:

In recent Swift, #if does not allow newlines in the condition.

% cat test.swift
#if os(OSX) || 
    ((os(iOS) || os(AppleTVOS)) && (arch(i386) || arch(arm))) || 
    (os(watchOS) && arch(i386))
    print("foo")
#else
    print("bar")
#endif

% xcrun -sdk macosx swiftc test.swift
test.swift:1:5: error: expected '&&' or '||' expression
#if os(OSX) || 
    ^

[SR-27] Passing variadic function as a function parameter crashes compiler with SIGSEGV

Previous ID	SR-27
Radar	None
Original Reporter	nate (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Environment

El Capitan, late 2013 Retina MacBook Pro

Apple Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f829)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: df05c318f165adcec0ebd665df8e3438

relates to:

• SR-41 Covariance does not work for functions with variadic arguments

Issue Description:

If I define a variadic function:

func variadic(integers: Int...) {}

I would expect this to be acceptable anywhere Int -> (), (Int, Int) -> (), etc. were. For example:

func variadic(integers: Int...) {}

[1].forEach(variadic)
[(1, 2)].forEach(variadic)

However, the compiler crashes with this error:

0  swift                    0x00000001043da47b llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43
1  swift                    0x00000001043d9916 llvm::sys::RunSignalHandlers() + 70
2  swift                    0x00000001043daaa3 SignalHandler(int) + 243
3  libsystem_platform.dylib 0x00007fff9573052a _sigtramp + 26
4  swift                    0x000000010235e6fe swift::Lowering::TypeConverter::find(swift::Lowering::TypeConverter::TypeKey) + 142
5  swift                    0x00000001023c0b09 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 4393
6  swift                    0x00000001023bc047 swift::Lowering::SILGenFunction::emitExprInto(swift::Expr*, swift::Lowering::Initialization*) + 279
7  swift                    0x000000010239c2ae (anonymous namespace)::ArgEmitter::emit(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) + 1950
8  swift                    0x000000010239c835 (anonymous namespace)::ArgEmitter::emitExpanded(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) + 261
9  swift                    0x000000010239c689 (anonymous namespace)::ArgEmitter::emit(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) + 2937
10 swift                    0x000000010239d7dd (anonymous namespace)::ArgEmitter::emitShuffle(swift::Expr*, swift::Expr*, llvm::ArrayRef<swift::TupleTypeElt>, swift::ConcreteDeclRef, llvm::ArrayRef<swift::Expr*>, llvm::ArrayRef<int>, llvm::ArrayRef<unsigned int>, swift::Type, swift::Lowering::AbstractionPattern) + 2429
11 swift                    0x000000010239cdd5 (anonymous namespace)::ArgEmitter::emitExpanded(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) + 1701
12 swift                    0x000000010239c689 (anonymous namespace)::ArgEmitter::emit(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) + 2937
13 swift                    0x000000010239b55b (anonymous namespace)::CallSite::emit(swift::Lowering::SILGenFunction&, swift::Lowering::AbstractionPattern, (anonymous namespace)::ParamLowering&, llvm::SmallVectorImpl<swift::Lowering::ManagedValue>&, llvm::SmallVectorImpl<std::__1::pair<swift::Lowering::LValue, swift::SILLocation> >&, llvm::Optional<swift::ForeignErrorConvention> const&) && + 315
14 swift                    0x00000001023900ba (anonymous namespace)::CallEmission::apply(swift::Lowering::SGFContext) + 2698
15 swift                    0x000000010238ee0a swift::Lowering::SILGenFunction::emitApplyExpr(swift::Expr*, swift::Lowering::SGFContext) + 58
16 swift                    0x00000001023bfae8 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 264
17 swift                    0x00000001023bfbb9 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 473
18 swift                    0x00000001023bea0f swift::Lowering::SILGenFunction::emitRValueAsSingleValue(swift::Expr*, swift::Lowering::SGFContext) + 47
19 swift                    0x000000010237dbd4 swift::Lowering::ArgumentSource::getAsSingleValue(swift::Lowering::SILGenFunction&, swift::Lowering::SGFContext) && + 340
20 swift                    0x000000010239c563 (anonymous namespace)::ArgEmitter::emit(swift::Lowering::ArgumentSource&&, swift::Lowering::AbstractionPattern) + 2643
21 swift                    0x000000010239b55b (anonymous namespace)::CallSite::emit(swift::Lowering::SILGenFunction&, swift::Lowering::AbstractionPattern, (anonymous namespace)::ParamLowering&, llvm::SmallVectorImpl<swift::Lowering::ManagedValue>&, llvm::SmallVectorImpl<std::__1::pair<swift::Lowering::LValue, swift::SILLocation> >&, llvm::Optional<swift::ForeignErrorConvention> const&) && + 315
22 swift                    0x00000001023900ba (anonymous namespace)::CallEmission::apply(swift::Lowering::SGFContext) + 2698
23 swift                    0x000000010238ee0a swift::Lowering::SILGenFunction::emitApplyExpr(swift::Expr*, swift::Lowering::SGFContext) + 58
24 swift                    0x00000001023bfae8 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 264
25 swift                    0x00000001023bec96 swift::Lowering::SILGenFunction::emitIgnoredExpr(swift::Expr*) + 486
26 swift                    0x0000000102387de6 swift::Lowering::SILGenModule::visitTopLevelCodeDecl(swift::TopLevelCodeDecl*) + 182
27 swift                    0x000000010238841b swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, unsigned int) + 827
28 swift                    0x0000000102388e62 swift::SILModule::constructSIL(swift::ModuleDecl*, swift::SILOptions&, swift::FileUnit*, llvm::Optional<unsigned int>, bool, bool) + 802
29 swift                    0x0000000102389216 swift::performSILGeneration(swift::ModuleDecl*, swift::SILOptions&, bool, bool) + 38
30 swift                    0x00000001021cb390 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&) + 11424
31 swift                    0x00000001021c84e3 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 2691
32 swift                    0x00000001021c4285 main + 2821
33 libdyld.dylib            0x00007fff98c265ad start + 1
Stack dump:
0.  Program arguments: /Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-01-a.xctoolchain/usr/bin/swift -frontend -interpret test.swift -target x86_64-apple-macosx10.9 -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -color-diagnostics -module-name test
fish: Job 1, '/Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-01-a.xctoolchain/usr/bin/swift test.swift' terminated by signal SIGSEGV (Address boundary error)

If this is not currently intended to permissible in the language, the crash should be fixed and a compiler error should be printed instead. For example:

func variadic(integers: Int...) {}

struct Variadic
{
    let function: Int -> ()
}

Variadic(function: variadic)

Prints the error:

test.swift:8:20: error: cannot convert value of type '(Int...) -> ()' to expected argument type 'Int -> ()'
Variadic(function: variadic)

[SR-2] Build configuration directives can not wrap switch cases

Previous ID	SR-2
Radar	rdar://problem/18841045
Original Reporter	@jopamer
Type	Improvement
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	5
Component/s	Compiler
Labels	Improvement, Parser
Assignee	@rintaro
Priority	Medium

Watchers: @shahmishal

md5: ac72c1f2b3e90602adfe008ab2456590

relates to:

• SR-4196 Allow #if (conditional compilation) to guard switch cases

Issue Description:

This code should be accepted, but it is rejected now:

switch 10 {
  case 10:
    break
#if FOO
  case 20:
    break
#endif
}

$ swiftc /tmp/a.swift
/tmp/a.swift:5:3: error: 'case' label can only appear inside a 'switch' statement
  case 20:
  ^

[SR-7] Inferring closure param type to inout crashes compiler

Previous ID	SR-7
Radar	rdar://problem/22813050
Original Reporter	@jopamer
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@gregomni
Priority	Medium

md5: 706aa076b5d0c32439e4d8e8563b7862

Issue Description:

If you attempt to compile the following program, the compiler crashes:

func f(inout a: Int) {}
let g = { x in f(x) }

[SR-8] Crash on invalid protocol usage

Previous ID	SR-8
Radar	rdar://problem/22772999
Original Reporter	@jopamer
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@jopamer
Priority	Medium

md5: 745dccb345b1970eabcd5bf9c431d7e0

Issue Description:

The following fragment of invalid code crashes the compiler:

protocol P {
    typealias T
    var env: T { get }
    func f(a: Int);
}

struct IgnoreInt: P {
    typealias T = Int
    var env: T
    func f(a: Int) { }
}

class IntBox {
    var value: Int
    init(value: Int) { self.value = value; }
}

struct AssignIntBox: P {
    typealias T = IntBox
    var env: T
    func f(a: Int) { env.value = a }
}

var a: P = IgnoreInt(env: 0)
var b: P = AssignIntBox(env: IntBox(value: 0))
b = a
b.f(1);

[SR-23] Build fails on Ubuntu 14.04.1 -> error: opening ... 'SwiftShims': No such file

Previous ID	SR-23
Radar	None
Original Reporter	manyoso (JIRA User)
Type	Bug

Attachment: Download

Environment

apple/swift (master)> uname -a
Linux atreat-thinkpad 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Following the instructions on README.md with new clones of all repos...

Additional Detail from JIRA

Votes	5
Component/s
Labels	Bug
Assignee	@bitjammer
Priority	Medium

md5: e8eced68282d2665cd7e220f9f5f2b15

is duplicated by:

• SR-333 Compiling hello world fails on ARM Linux

Issue Description:

apple/swift (master)> uname -a
Linux atreat-thinkpad 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Compiling /home/atreat/dev/personal/apple/build/Ninja-DebugAssert/swift-linux-x86_64/stdlib/public/core/linux/x86_64/Swift.o

...

/home/atreat/dev/personal/apple/swift/stdlib/public/core/ArrayBody.swift:18:8: error: opening import file for module 'SwiftShims': No such file or directory
import SwiftShims
^
ninja: build stopped: subcommand failed.
./utils/build-script: command terminated with a non-zero exit status 1, aborting

I've attached the full compile line and error

[SR-41] Covariance does not work for functions with variadic arguments

Previous ID	SR-41
Radar	rdar://23011851
Original Reporter	nikita (JIRA User)
Type	Bug

Attachment: Download

Environment

Xcode 7.1.1 (7B1005)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 1344eed40e3fc0135966b4277a47f007

relates to:

• SR-27 Passing variadic function as a function parameter crashes compiler with SIGSEGV

Issue Description:

Swift 2.2 covariance unable to resolve functions covariance with variadic arguments.

Steps to Reproduce:
Attached a playground that shows the problem, as well as screenshot with errors. Here is a copy & paste of the code for your convenience:

func giveMeVoid(callback: (Void)->Void) {
    
}

func giveMeInt(callback: (Int)->Void) {
    
}

func any(values:Any?...) {
    
}

any()
any(5)

giveMeVoid(any) //This line will fail
giveMeInt(any) //This line will fail

Expected Results:
It is expected that `any` will be accepted by both giveMeVoid and giveMeInt functions, as they can work as `Void` and `Int` functions when they called directly.

Actual Results:
Non of functions accept 'any'. Following errors are thrown:

error: cannot convert value of type '(Any?...) -> ()' to expected argument type '(Void) -> Void'
error: cannot convert value of type '(Any?...) -> ()' to expected argument type '(Int) -> Void'

[SR-76] Bridging header support either missing or undocumented

Previous ID	SR-76
Radar	None
Original Reporter	jjl (JIRA User)
Type	Bug

Environment

Linux/gentoo

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 843cc2c4cddbb5da8ef07681f244739a

Issue Description:

I can't find any way to use a bridging header without using xcode. Is this feature missing, implemented in xcode or merely undocumented?

[SR-78] swiftc crushed for very simple code

Previous ID	SR-78
Radar	None
Original Reporter	windoze (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Ubuntu 14.04.3 LTS x86_64, Ubuntu 14.04 Swift 2.2 Snapshot

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, CompilerCrash
Assignee	@jckarter
Priority	Medium

md5: 4ce09acd58663f0925c8dc1bdf749fe1

Issue Description:

Following piece of code effectively crushes swiftc

struct A<T1, T2> {
    var f:B<T1, T2>
    var b:B<T2, T1>
    var v:T1
}
struct B<T1, T2> {}

Logs attached

[SR-10] Demangler crashes on method signature

Previous ID	SR-10
Radar	rdar://problem/22164428
Original Reporter	@jopamer
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@jopamer
Priority	Medium

md5: 0de69f21021d970867b18eeb66152a02

Issue Description:

The following mangled string crashes the demangler:

_TtFQQQq_FSs5splitu0_Rq_Ss14CollectionTypeq0_Ss11BooleanType_FTq_8maxSplitSi16allowEmptySlicesSb11isSeparatorFqqq_S_9GeneratorSs13GeneratorType7Elementq0__GSaqq_S_11SubSequence_9Generator7ElementQq0_FSs5splitu0_Rq_Ss14CollectionTypeq0_Ss11BooleanType_FTq_8maxSplitSi16allowEmptySlicesSb11isSeparatorFqqq_S1_9GeneratorSs13GeneratorType7Elementq0__GSaqq_S1_11SubSequence_

[SR-34] Port Swift to Windows

Previous ID	SR-34
Radar	None
Original Reporter	add210 (JIRA User)
Type	New Feature
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	11
Component/s
Labels	New Feature, NewPortRequest, Windows
Assignee	@compnerd
Priority	Medium

md5: f4b64a255a413f9bd9346ba92309927c

relates to:

• SR-1131 Build script for MSVC on Windows

Issue Description:

Port Swift to Windows. This effectively breaks into a few ports (see linked issues) but the important ones being:

❌ Port to Visual Studio (MSVC)
❌ Port to Cygwin

This is actively being worked on here by tinysun (JIRA User): https://github.com/tinysun212/swift-windows

[SR-26] Please add Chinese language

Previous ID	SR-26
Radar	None
Original Reporter	rongshuxia (JIRA User)
Type	Improvement

Additional Detail from JIRA

Votes	1
Component/s
Labels	Improvement
Assignee	None
Priority	Medium

md5: 6e0b6622fa7c9a1f2c0d0dbc1d988dc7

Issue Description:

Please add the Chinese language for swift.org

[SR-6] Improve the AST verifier

Previous ID	SR-6
Radar	rdar://problem/17858620
Original Reporter	@jopamer
Type	Task
Status	Reopened
Resolution

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Task
Assignee	None
Priority	Medium

md5: c8813366828ca436433065a7b8e88402

Issue Description:

We get a lot of bugs that land in backend components because they crash in SILGen, optimization, or IRGen, but are really rooted in type-checker bugs. To help better screen these bugs, and to hopefully catch them sooner, we should put some effort into the AST verifier to make it check more invariants. Currently it misses a lot of basic things, like 'ParenExprs shouldn't change the type of the subexpression' or '*MemberRef should reference a member that's actually reachable from the base type'.

[SR-36] Serialization/write-to-locked-dir.swift test failure in Ubuntu while on NTFS drive

Previous ID	SR-36
Radar	None
Original Reporter	anidotnet (JIRA User)
Type	Bug

Environment

OS - Ubuntu 15.10
Arch - Intel x86_64 (core i7)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 449d27fb86d12376c53d9aba3cace98a

Issue Description:

While compiling swift from Github source in Ubuntu 15.10, I am getting below test failure when the source files are placed inside a NTFS partition.

lit.py: lit.cfg:759: note: Using platform module dir: /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/%target-sdk-name/x86_64
FAIL: Swift :: Serialization/write-to-locked-dir.swift (1766 of 2332)
******************** TEST 'Swift :: Serialization/write-to-locked-dir.swift' FAILED ********************

Script:
--
rm -rf /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp && mkdir /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp
touch /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp/main.swiftmodule /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp/main.swiftdoc
chmod -w /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp
/media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift -frontend -target x86_64-unknown-linux-gnu  -emit-module -emit-module-doc -parse-stdlib -o /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp -module-name main /media/anindya/Misc/codebase/swift/swift/test/Serialization/write-to-locked-dir.swift || chmod +w /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp
chmod +w /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp
test -s /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp/main.swiftmodule
test -s /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp/main.swiftdoc
--
Exit Code: 1

Command Output (stderr):
--
chmod: /media/anindya/Misc/codebase/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/test-linux-x86_64/Serialization/Output/write-to-locked-dir.swift.tmp: new permissions are r-xrwxrwx, not r-xr-xr-x

--

********************
Testing Time: 66.60s
********************
Failing Tests (1):
    Swift :: Serialization/write-to-locked-dir.swift

  Expected Passes    : 1666
  Expected Failures  : 92
  Unsupported Tests  : 573
  Unexpected Failures: 1
*** Failed while running tests for swift (check-swift-linux-x86_64)
./swift/utils/build-script: command terminated with a non-zero exit status 1, aborting

[SR-30] Enumerations could have a "allValues" property

Previous ID	SR-30
Radar	rdar://problem/17102392
Original Reporter	RuiCarneiro (JIRA User)
Type	Improvement
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	6
Component/s
Labels	Improvement, LanguageFeatureRequest
Assignee	@CodaFi
Priority	Medium

md5: 6f9747e0e0648c9bf5fee84b0f66cd7f

relates to:

• SR-3050 enum cases should be enumerable

Issue Description:

Sometimes, it's convenient to have an allValues property for an enum that automatically generates a collection with all possible elements.

eg:

{{enum Fruits { case Apple, Orange, Peach, Banana }

for fruit in Fruits.allValues {
// ...
}}}

{color:red}On another note, it would be handy to have a reverse function for the rawValue propriety

eg:

{{enum Fruits : Int { case Apple = 0, Orange ... }

let fruit : Fruits? = Fruits.reverseRawValue(1)

// fruit == Fruits.Orange}}{color}

Thanks, Kevin Ballard.

[SR-5] [Iterative Decl Checker] Recursive type alias defaults crash the compiler

Previous ID	SR-5
Radar	rdar://problem/20985232
Original Reporter	@jopamer
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: e8b560bec251784192ee46b1939df9f3

Issue Description:

The following code fragment crashes the compiler:

protocol P {
  typealias A = B
  typealias B = A

  func f(a: A) -> B
  func f(b: B) -> A
}

extension P {
  func f(a: A) -> B { repeat {} while true }
  func f(a: B) -> A { repeat {} while true }
}

[SR-44] Checking protocol adherence of self in a static function produces LLVM ERROR

Previous ID	SR-44
Radar	None
Original Reporter	dhogborg (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Apple Swift version 2.1 (swiftlang-700.1.101.6 clang-700.1.76)
Target: x86_64-apple-darwin15.0.0

XCode 7.1.1

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, IRGen
Assignee	None
Priority	Medium

md5: 21024ad993e0d6972717c96c9ea9af7d

Issue Description:

Xcode and Playgrounds thinks this is valid code. Not until swiftc try to compile it the error is discovered. At that point it's not clear where the error is located as Xcode does not give any more information than the comment below. Playgrounds generates a crash log when communication is interrupted unexpectedly.

Checking protocol adherence of a subclass in a static function is not caught by linter and produces a really unhelpful error message. This should be caught and referenced by line of code where the error is located.

protocol ChildProt : class {
    init()
    func name() -> String
}


class Parent {
    
    required init() {}
    
    static func queryChildren() -> [ChildProt] {
        // don't try to check a protocol adherence of self in a static function
        guard let prot = self as? ChildProt else {
            preconditionFailure()
        }
        return [prot.dynamicType.init()]
    }
    
}

class Child : Parent, ChildProt {
    
    var NAME = "John Doe"
    
    required init() {}
    
    func name() -> String {
        return self.NAME
    }
}

let child = Child.queryChildren().first!
child.name()

After hunting down the offending file, this is the error message produced by swiftc and presented in Xcode.

 Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1

 PHI nodes must have at least one entry.  If the block is dead, the PHI should be removed!
 %50 = phi i8** , !dbg !530
 LLVM ERROR: Broken function found, compilation aborted!

Playground with example code attached

[SR-48] Create warning for missing self in lazy var initialization

Previous ID	SR-48
Radar	rdar://22067698
Original Reporter	hagi (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Attachment: Download

Environment

Verified with Apple Swift version 2.1.1 and Apple Swift version 2.2-dev
OS X 10.11.1 (15B42). Requires Foundation framework and ObjC runtime.

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: 484aa387c639f336a3aed7547f1776b1

is duplicated by:

• SR-484 Bad error message for lazy var

relates to:

• SR-484 Bad error message for lazy var
• SR-2203 Implicit self doesn't work in initializer of lazy var
• SR-4663 Bad diagnostic when missing explicit type in lazy property declaration

Issue Description:

Usually, when `self` is missing from a call within a closure, a warning is generated (unless you explicitly capture `self`). This generally holds true for closures used to initialize lazy variables.

However, I've found that some methods (possible `objc`-related) don't require `self` to compile without warnings, but they don't work as expected either, which leads to bugs that are really easy to miss and a pain to find. It would be great to have warnings in these cases.

Steps to Reproduce:
Please see the file attached. On OS X, you can just run `swift lazy_block.swift` in the Terminal (from the respective directory).

Please read the comments in the file, too.

Expected Results:
The naive expectation when I encountered the bug was that `respondsToSelector` (line 16) would be called on the instance and return `true` (but it returns `false`).

The correct expectation should be a warning/error in that line, and possibly a fix-it, leading to what I've written in line 22 (which does return/print `true`).

Actual Results:
No warning/error, but `respondsToSelector` does not return the expected result.

Notes:
This problem does not seem to occur in normal closures (see lines 51 ff). I could only reproduce this in lazy variable initializations.

This has been filed as a radar before, but I think this bug tracker offers a better chance of getting attention from the Swift team or the general community. For reference: rdar://22067698. The example has been updated/simplified, so please prefer this bug report over the radar.

[SR-16] debug-time-function-bodies' output isn't precise enough

Previous ID	SR-16
Radar	None
Original Reporter	maxs (JIRA User)
Type	Improvement
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Improvement
Assignee	add210 (JIRA)
Priority	Medium

md5: a841b95419429fa37d43c78e96c6bee6

Issue Description:

If you use debug-time-function-bodies to determine which parts of your code are slow to compile you might notice the numbers don't add up. For me, it only added up to half the amount of time in the profile trace. This is because it rounds to only one decimal place! We should print with two, or even more, decimal places so the time adds up correctly.

[SR-55] non-@objc protocol existentials do not conform to their own protocol type

Previous ID	SR-55
Radar	rdar://problem/21341337
Original Reporter	siarhei.barysenka (JIRA User)
Type	Bug

Attachment: Download

Additional Detail from JIRA

Votes	40
Component/s	Compiler
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: 4333a622f7ff4546521a5fc9f3702a7d

is duplicated by:

• SR-1176 Using protocols (inheriting from class) as generic parameter which needs to be of type AnyObject fails
• SR-1324 Passing a parameter of type protocol P to a generic method with a protocol P constraint fails
• SR-1581 Can not use protocol to fulfill associatedtype requirement where associatedType has protocol constraint
• SR-2020 Protocol composition doesn't conform to associated type requirement
• SR-2580 Call to a generic function that expects argument to conform a protocol fails if argument compose multiple protocols.
• SR-2704 T: Protocol generic constraint doesn't accept protocol existentials
• SR-3038 Cannot pass in a protocol type to a constrained generic parameter
• SR-5188 Class existentials don't conform to protocols that the class conforms to
• SR-5341 Protocol with associatedtype constrained to another protocol & inheritance does not compile
• SR-5357 Type-constrained protocol cannot be used as a generic argument for similarly constrained generic parameter
• SR-5777 Existential Metatype in generics
• SR-6039 A protocol A: class is not any AnyObject
• SR-6173 Problems with generics + AnyObject or class protocol conformance
• SR-6645 EXC_BAD_ACCESS in code using protocol extension for defining default implementation
• SR-7008 Subclass existential doesn't satisfy generic class constraints
• SR-7412 Swift crashes when a class conforms to a protocol with associated type as AnyObject
• SR-7563 Generic class with AnyObject constraint won't except protocol that also has AnyObject constraint
• SR-8261 Generics don't identify Protocol with class requirement properly
• SR-8624 Unable to use protocol with class type where AnyObject is expected
• SR-8637 'Protocol composition type' with generic types/inheritance
• SR-8893 AnyObject constraint on generic type parameter doesn't work when a protocol type is passed as an argument
• SR-10031 Constraints involving a Class & Protocol constraint don't type check correctly
• SR-10053 Protocols extending class types are not recognized as class types

relates to:

• SR-7332 Conditional conformance over array of heterogenous values that share a protocol conformance fails
• SR-10991 Function Builders & Opaque return types error Xcode 11 / Swift 5.1
• SR-10907 Default implementation not picked up when conforming to two protocols at once
• SR-1581 Can not use protocol to fulfill associatedtype requirement where associatedType has protocol constraint
• SR-7343 Generic constraint fails to infer type when expecting sub protocol

Issue Description:

Summary:
The compiler throws the error

generic parameter 'T' could not be inferred

at the final line of the following code:

protocol MediaProtocol {}
protocol ImageProtocol: MediaProtocol {}

class Image: ImageProtocol {}

func itemToProcess() -> ImageProtocol {
    return Image()
}

//func process<T>(item: T) -> T { // Uncomment this line and comment out the following one to remove the compile-time error
func process<T: MediaProtocol>(item: T) -> T {
    return item
}

let image = itemToProcess()
let processedImage: ImageProtocol = process(image)

The error is gone when conformance to `MediaProtocol` is removed from the generic type `T` at the `process` method declaration in the given code.

Reproduced on:
Xcode 7.1.1 (7B1005), Swift 2.1, OS X 10.11

[SR-56] .dynamicType is missing from Code Completion

Previous ID	SR-56
Radar	rdar://problem/22072865
Original Reporter	maxs (JIRA User)
Type	Bug
Status	Closed
Resolution	Invalid

Additional Detail from JIRA

Votes	1
Component/s	Source Tooling
Labels	Bug
Assignee	None
Priority	Medium

md5: f252571ad84e5a238abce91ad79e5cf6

Issue Description:

Component: SourceKit

dynamicType is missing from code completion.

To test this, use swift-ide-test. I.e.

File: cc.swift

String().#\A\#

Run:

swift-ide-test -code-completion -source-filename=cc.swift -code-completion-token=A cc.swift

Note that dynamicType is missing from the output.

[SR-62] Compiler crash caused by conforming to generic protocol which references another generic protocol

Previous ID	SR-62
Radar	None
Original Reporter	patgoley (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, CompilerCrash
Assignee	cwillmore (JIRA)
Priority	Medium

md5: 0a5df40af9435ae8a4d06d5c4a3ae9de

Issue Description:

The following swift program crashes the compiler:

import Foundation

protocol Model {
    
    typealias IdentifierType
    
    var id: IdentifierType {get}
}

protocol Repository {
    
    typealias ModelType: Model
    
    func findById(id: ModelType.IdentifierType) -> (ModelType)
}

extension NSObject: Model {
    
    var id: IdentifierType {
        
        get {
            
            return 5
        }
    }
}

class ObjectRepository<T where T: NSObject> : Repository {
    
    func findById(id: T.IdentifierType) -> T {
        
        return T()
    }
}

It seems like the compiler should be able to recognize that ObjectRepository conforms to Repository because NSObject conforms to Model which ObjectRepository<T> is constrained to.

[SR-49] White text on white terminal background makes text invisible on Ubuntu

Previous ID	SR-49
Radar	None
Original Reporter	jpedrosa (JIRA User)
Type	Bug
Status	Closed
Resolution	Invalid

Attachment: Download

Additional Detail from JIRA

Votes	0
Component/s
Labels	Bug
Assignee	None
Priority	Medium

md5: d5358959d25086eb305674fe4790c463

Issue Description:

Hi,

Thanks for Swift.

While testing it on Ubuntu, error messages with white text on my terminal's white background made the text invisible. The word "error" would show up in red, but the other parts would only show up when I selected the text as if I was going to copy/paste it.

Here's a sample run:

$ swift woe.swift
woe.swift:3:7: error: value of type 'String' has no member 'utf4'
print("Hello".utf4)
^~~~~~~ ~~~~
$ cat woe.swift

print("Hello".utf4)

Only the "error:" shows up as red. Surrounding text is white. I will attach the screenshot too.

[SR-64] Allow generic parameters on typealiases

Previous ID	SR-64
Radar	None
Original Reporter	@lilyball
Type	Improvement
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Improvement, LanguageFeatureRequest
Assignee	None
Priority	Medium

md5: 1ffbbd3dbec72831eafe2d1921c680d6

Issue Description:

It would be really handy if typealiases could take generic parameters, e.g.

typealias Handler<Element> = [Element] -> Void

[SR-65] build-script generates CMAKEGENERATE without quotes

Previous ID	SR-65
Radar	None
Original Reporter	liangz (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Environment

Macbook Air with OS X Ei Capitan

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, BuildScript
Assignee	None
Priority	Medium

md5: da5a5c9c9d5a1fb51b76d97c9f088459

Issue Description:

I am using Macbook Air with OS X EI Capitan, and I am building swift (commit number c959ce2) with the following command.
./build-script --debug-swift --make --build-subdir ../../build

The error is "CMake Error: Could not create named generator Unix".
Then, I copy the generated command and insert quotes for Unix Makefiles.
It builds correctly. I think there are something missing in the build-script for adding the quotes.

[SR-20] Update swift --help to explain multitool support ("swift build", etc.)

Previous ID	SR-20
Radar	rdar://problem/28814419
Original Reporter	Beard (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s
Labels	Bug
Assignee	kelhutch17 (JIRA)
Priority	Medium

md5: 90d00a5d61e6a0083ac90f27e5a0de5b

is duplicated by:

• SR-6348 Swift usage message should mention swiftpm commands
• SR-1587 swift --help doesn't mention the swiftpm subcommands: package, build, test

relates to:

• SR-6347 SwiftPM command usage messages should mention other top-level commands

Issue Description:

When you execute swift --help, there should be some text that explains "swift build" to make it more discoverable. "swift build --help" does correctly execute swift-build --help.

[SR-43] Setting setter of var before getter makes SourceKit crashes

Previous ID	SR-43
Radar	None
Original Reporter	Sylvain (JIRA User)
Type	Bug
Status	Closed
Resolution	Cannot Reproduce

Environment

Xcode 7.1.1

Additional Detail from JIRA

Votes	1
Component/s	Source Tooling
Labels	Bug
Assignee	None
Priority	Medium

md5: f0e97f4e0c6ff7487db9062463d7658b

Issue Description:

The code below makes SourceKit crash until you implement get :

var foo: String {
    set {
    }
}

[SR-69] [QOI] Poor diagnostic with non-Range in for loop

Previous ID	SR-69
Radar	None
Original Reporter	@ddunbar
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, DiagnosticsQoI
Assignee	@gregomni
Priority	Medium

md5: ec6e593e3561b9b848b6e71011de74ba

Issue Description:

Swift produces a poor diagnostic on this example:

$ cat t.swift
func foo() {
    for i in min(1,2) {
    }
}

$ swiftc -c t.swift
t.swift:2:14: error: cannot invoke 'min' with an argument list of type '(Int, Int)'
    for i in min(1,2) {
             ^
t.swift:2:14: note: expected an argument list of type '(T, T)'
    for i in min(1,2) {
             ^

It should tell me I forgot to make a range.

[SR-37] RawRepresentable enum types should be auto unpacked.

Previous ID	SR-37
Radar	None
Original Reporter	blach (JIRA User)
Type	Improvement

Additional Detail from JIRA

Votes	1
Component/s
Labels	Improvement
Assignee	None
Priority	Medium

md5: 821bcb1fe2c1f28e6ac53d7cfb2e0ad6

relates to:

• SR-3177 Should @objc enums be bridged to Objective-C as their raw value?

Issue Description:

In many cases it seems most natural to store application level constants in an enum. For instance:

enum Constants {
    enum Notifications {
        case LoggedIn
        case LoggedOut
    }
}

As one would expect (and as of Swift 2) you can now

print(Constants.Notifications.LoggedOut) // "LoggedOut"

This is because of the addition of the CustomStringConvertable protocol. However in similar situations where one might want to pass an enum as it's raw representation, it fails:

NSNotificationCenter.defaultCenter().postNotificationName(Constants.Notifications.LoggedOut, object: nil, userInfo: nil) // Can not convert 'Constants.Notifications.LoggedOut' to type 'String'

This seems counter intuitive. Especially in the case of an enum with an explicitly typed raw value (e.g. enum Notifications: String). This has lead to a plethora of work arounds. Here are three:

// 1
extension NSNotificationCenter {
    func postNotificationName(name: Constants.Notifications, object anObject: AnyObject?, userInfo aUserInfo: [NSObject : AnyObject]? = nil) {
        self.postNotificationName(name.rawValue, object: anObject, userInfo: aUserInfo)
    }
}

// 2
extension NSNotificationCenter {
    func postNotificationName<T: RawRepresentable where T.RawValue == String>(name: T, object anObject: AnyObject?, userInfo aUserInfo: [NSObject : AnyObject]? = nil) {
        self.postNotificationName(name.rawValue, object: anObject, userInfo: aUserInfo)
    }
}

// 3 
https://gist.github.com/designatednerd/5645d286df0ce939714b

// I really don't get the trouble that this last person went to, because it doesn't yield anything you'd actually want to use, but oh well.

In light of this, RawRepresentable types logically should map to their raw values when passed as arguments of that specified types, such that a simple

[SR-75] Referencing a protocol function crashes the compiler

Previous ID	SR-75
Radar	rdar://21289579
Original Reporter	Sephiroth87 (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Xcode 7.1.1

Additional Detail from JIRA

Votes	4
Component/s	Compiler
Labels	Bug, CompilerCrash
Assignee	@slavapestov
Priority	Medium

md5: 85007b8954c0d9c1507fbd1a12838bdf

is duplicated by:

• SR-2544 Compiler crash on access to protocol function
• SR-3036 Crash When Calling Curried Instance Method on Protocol
• SR-3670 Calling default implementation as a curried method causes compiler crash
• SR-4375 Using Generic with Protocols causes Segmentation Fault
• SR-5638 Compiler Crash - Protocol Function Reference
• SR-6234 Compiler crashes with protocol P { func f() }; type(of: P.f)
• SR-7264 Compile-time segmentation fault while referencing protocol method
• SR-7633 Compiler crash (Segmentation Fault 11) when assigning protocol method to variable
• SR-7968 Compiler crash when accessing protocol extension method by type name
• SR-8654 Trying to get Protocol.method crashes the compiler
• SR-8904 Compiler crash when using protocol function as member of protocol.
• SR-9053 Compiler crashes with Segmentation fault
• SR-9147 Compiler crash in lowering
• SR-9779 Crash while emitting SIL for curried call to protocol instance method
• SR-10345 Compiler crash on invalid closure syntax
• SR-10618 Trying to get a reference to a protocol's member crashes the compiler
• SR-10815 Protocol method partial application seg fault
• SR-11769 Crash when attempting to assign an unbound method from a protocol
• SR-12589 Segmentation Fault when compiling instance method call from protocol
• SR-12604 Crash creating unbound reference to protocol method
• SR-12657 Swift 5.2 compiler crash, protocol method reference
• SR-5240 Creating a reference to a protocol-based function crashes the compiler

relates to:

• SR-1329 LLVM error when assigning protocol function to variable

Issue Description:

The following code will crash the compiler

protocol MyProtocol {
    func myFunc() -> String
}

let f = MyProtocol.myFunc

[SR-38] "protocol can only be used as a generic constraint" errors reported twice

Previous ID	SR-38
Radar	None
Original Reporter	@lilyball
Type	Bug
Status	Resolved
Resolution	Done

Environment

Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift e8a15c6)
Target: x86_64-apple-macosx10.9
Compiled with the default build-script settings

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, DiagnosticsQoI, TypeChecker
Assignee	@gregomni
Priority	Medium

md5: d13102ac8bfee811237d0ecbc6545377

Issue Description:

The code snippet from SR-8 illustrates a curious bug:

protocol P {
    typealias T
    var env: T { get }
    func f(a: Int);
}

struct IgnoreInt: P {
    typealias T = Int
    var env: T
    func f(a: Int) { }
}

class IntBox {
    var value: Int
    init(value: Int) { self.value = value; }
}

struct AssignIntBox: P {
    typealias T = IntBox
    var env: T
    func f(a: Int) { env.value = a }
}

var a: P = IgnoreInt(env: 0)
var b: P = AssignIntBox(env: IntBox(value: 0))
b = a
b.f(1);

In Swift 2.1 (swiftlang-700.1.101.6), this correctly emits two errors:

foo.swift:24:8: error: protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements
var a: P = IgnoreInt(env: 0)
       ^
foo.swift:25:8: error: protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements
var b: P = AssignIntBox(env: IntBox(value: 0))
       ^

Current tip of master emits each error twice, once for the protocol type, and then again for the variable:

foo.swift:24:8: error: protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements
var a: P = IgnoreInt(env: 0)
       ^
foo.swift:24:5: error: protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements
var a: P = IgnoreInt(env: 0)
    ^
foo.swift:25:8: error: protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements
var b: P = AssignIntBox(env: IntBox(value: 0))
       ^
foo.swift:25:5: error: protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements
var b: P = AssignIntBox(env: IntBox(value: 0))
    ^

[SR-15] Glibc module doesn't work with Gentoo: prefix is /usr/include/sys, not /usr/include/x86_64-linux-gnu/sys

Previous ID	SR-15
Radar	None
Original Reporter	@octoploid
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	1
Component/s
Labels	Bug, Linux
Assignee	@bitjammer
Priority	Medium

md5: d5a5cc8c191684fcb73a1cae75fc477f

Issue Description:

stdlib/public/Glibc/module.map contains hardcoded paths to glibc headers.
On my system all "module sys" paths are wrong, e.g.:

header "/usr/include/x86_64-linux-gnu/sys/ipc.h"
lives in /usr/include/sys/ipc.h on my system.

[SR-22] build fails when following the "getting started" on Ubuntu 14.04

Previous ID	SR-22
Radar	None
Original Reporter	hwang (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Environment

1:haohui@dell530n:~/source.swift/Hello[1019] 18:12:18
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"

1:haohui@dell530n:~/source.swift/Hello[1020] 18:14:48
$ ls Sources/
main.swift

1:haohui@dell530n:~/source.swift/Hello[1021] 18:15:45
$ cat Sources/main.swift
print("Hello, world!")

Additional Detail from JIRA

Votes	0
Component/s
Labels	Bug
Assignee	hwang (JIRA)
Priority	Medium

md5: 0cdbb920e39a03c96a783f1f4c28fd86

Issue Description:

1:haohui@dell530n:~/source.swift/Hello[1018] 18:12:08
$ swift build
Linking Executable: .build/debug/Hello
<unknown>:0: error: link command failed with exit code 127 (use -v to see invocation)
<unknown>:0: error: build had 1 command failures
swift-build: exit(1): ["/opt/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin/swift-build-tool", "-f", "/abyss/haohui/source.swift/Hello/.build/debug/Hello.o/llbuild.yaml"]

[SR-42] Implicit Optionals are not implicit on a tuple assignment.

Previous ID	SR-42
Radar	rdar://23632146
Original Reporter	nikita (JIRA User)
Type	Bug
Status	Reopened
Resolution

Attachment: Download

Environment

Xcode 7.1.1

Additional Detail from JIRA

Votes	4
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 9ec8a5c65eb1dc8d0c6f70183c84515b

Issue Description:

Summary:
It is impossible to unwrap non-optional tuple into a tuple of two implicitly optional variables of the same type. For example, following code will not work:

var first: Int!
var second: Int!

func tuple() -> (Int, Int) {
    return (0,0)
}

(first, second) = tuple()

Steps to Reproduce:
Assign tuple of non-optional types to a tuple of variables with an implicitly optional types.

Expected Results:
Variables will be assigned.

Actual Results:
Compiler will provide a error "cannot express tuple conversion '(Int, Int)' to '(Int)' (aka '(ImplicitlyUnwrappedOptional<Int>, ImplicitlyUnwrappedOptional<Int>)')"

[SR-68] SequenceType._preprocessingPass can cause duplicate evaluation of lazy collections

Previous ID	SR-68
Radar	None
Original Reporter	@lilyball
Type	Bug

Environment

Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 3dbfefa)

Additional Detail from JIRA

Votes	1
Component/s	Standard Library
Labels	Bug
Assignee	None
Priority	Medium

md5: d0004a1684c9d205b2caf0b3ae2fa8d3

Issue Description:

Code that uses SequenceType._preprocessingPass will have the closure executed when the collection is a lazy collection. This is a problem because the closure almost certainly is going to access some property that forces lazy evaluation (for maps, that would be iterating over the elements; for filters, even just accessing the count will evaluate the filter). And this is a bad idea because the overhead of extra evaluations of the lazy computations is probably worse than the performance gain from doing the preprocessing pass.

I've reproduced this with <SequenceType where Generator.Element == String>.joinWithSeparator(String) on a lazy map. This should apply to other situations as well. The test case for joinWithSeparator looks like

JoinTestSuite.test("StringCollection.joinWithSeparator()") {
  // make sure we only evaluate each element once
  func testLazyJoin(separator: String, _ elements: [String]) {
    var expectSeen: [Int: Int] = [:]
    for i in 0..<elements.count {
      expectSeen[i] = 1
    }
    var seen: [Int: Int] = [:]
    // elements needs to be a collection, not a sequence
    let elements = Array(elements.enumerate()).lazy.map({ (i, x) -> String in
      seen[i] = (seen[i] ?? 0) + 1
      return x
    })
    let _: String = elements.joinWithSeparator(separator)
    expectEqual(expectSeen, seen)
  }

  testLazyJoin("", ["a"])
  testLazyJoin("", ["a", "b", "c"])
  testLazyJoin("xy", ["ab", "cd", "ef"])
}

I'm unsure what the correct behavior here is. If we make _preprocessingPass skip the pass for lazy collections, that throws away some potential valid optimizations, such as relying on an exact count for lazy maps, or optimizing on lazy reverses. But the alternative is to define several classifications of "safe" preprocessing and have separate preprocessing methods for each classification, so e.g. a lazy filter will never preprocess, a lazy map can preprocess for computations involving just the collection indexes, and lazy reverses can do everything. If we do go down this route, we'll have to make sure the lazy collections actually query their underlying base collection too if they think they can handle the pass, because they might be wrapping some other lazy collection that can't.

[SR-17] Refactoring

Previous ID	SR-17
Radar	None
Original Reporter	krusche (JIRA User)
Type	New Feature
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	11
Component/s
Labels	New Feature
Assignee	@bitjammer
Priority	Medium

md5: ce13c69509de60ecfe1aaced5dc7c844

Issue Description:

Swift is a statically typed language and it would be great, if refactoring would be supported!

[SR-39] Unable to start REPL on Linux

Previous ID	SR-39
Radar	None
Original Reporter	nitingupta (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Environment

Linux x86_64:

• Ubuntu 15.10

• Fedora 23

Additional Detail from JIRA

Votes	0
Component/s
Labels	Bug
Assignee	nitingupta (JIRA)
Priority	Medium

md5: fd86c22c281bf15d4abce7ab7c984033

Issue Description:

I build swift from source on both Ubuntu 15.10 and Fedora 23 with:
utils/build-script -R
to get a release build.

But when I try to start REPL from build directory I'm getting following error (on both Linux flavors):

LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform

However I can run ./swiftc without errors.

Output of tests run with 'build-scripts -R -t':

Testing Time: 46.07s
Expected Passes : 1667
Expected Failures : 92
Unsupported Tests : 573

• • check-swift-linux-x86_64 finished --

    • Finished tests for swift ---

[SR-1] Linux: remove Swift dependence on the swift.ld linker script

Previous ID	SR-1
Radar	rdar://problem/22724955
Original Reporter	@jopamer
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	2
Component/s
Labels	Bug, Linux
Assignee	None
Priority	Medium

md5: 90c6fa571fac13d05c95850bed417233

Issue Description:

Building Swift on Linux currently depends on a linker script to mark protocol conformances. This linker script method is not compatible with the gold linker. We want to support using the gold linker, so come up with another method to achieve this that is compatible with the gold linker.

It seems likely there are at least the following options that seem potentially valid:

1. We could do some work inside the swift compiler itself as a pre-link step, to collate the protocol conformance data into a single object file. I think we’re ultimately looking for a section of data that we know the size and length of, that contains the conformance data, that can be accessed as a known symbol name at runtime.

2. Adjust the gold linker to support the symbol collation functionality in ld.bfd that is not in ld.gold. The gold linker is a GPLv3 project.

[SR-47] Public protocol extensions cannot have internal generic requirements

Previous ID	SR-47
Radar	None
Original Reporter	mhuusko5 (JIRA User)
Type	Bug
Status	Reopened
Resolution

Environment

Swift 2.1

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 86f7d721dca2d652e7f9808a7c9f03b9

Issue Description:

As seen below, I would like (/think I should be able) to provide default implementations for a protocol, when the type in question satisfies certain internal requirements. I believe this was possible in an earlier beta, but as of 2.1 it certainly isn't.

If this is not a bug, but by design (and the below has been deemed an anti-pattern), I'd be greatly interested in an alternative pattern (other than having the internal requirements actually public, but simply underscored, like the much of the standard library is).

public protocol ControllerType {
    func doImportantStuff() -> Bool
}

internal protocol _ControllerType {
    func implementationDetail() -> Bool
}

// error: extension cannot be declared public because its generic requirement uses an internal type
public extension ControllerType where Self: _ControllerType {
    public func doImportantStuff() -> Bool {
        return implementationDetail()
    }
}

public struct Con: ControllerType { }

extension Con: _ControllerType {
    func implementationDetail() -> Bool {
        return true
    }
}

let c = Con()

c.doImportantStuff()

[SR-50] Use 'try' statement to guide type inference

Previous ID	SR-50
Radar	None
Original Reporter	@akyrtzi
Type	Improvement
Status	Reopened
Resolution

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Improvement, TypeChecker
Assignee	None
Priority	Medium

md5: 9004a0727c0e0a404b014393e17c9bce

Issue Description:

With this code:

enum SomeError : ErrorType {
  case Error
}

enum SomethingOrError<T> {
  case err(SomeError)
  case some(T)
}

func doit() -> SomethingOrError<Int> {
  return SomethingOrError.some(0)
}

func doit() throws -> Int {
  return 0
}

let something = try! doit()

You get:

t.swift:18:22: error: ambiguous use of 'doit()'
let something = try! doit()
                     ^
t.swift:10:6: note: found this candidate
func doit() -> SomethingOrError<Int> {
     ^
t.swift:14:6: note: found this candidate
func doit() throws -> Int {
     ^

Consider guiding type inference to resolve the call to the throwing function since the call uses 'try'.

[SR-51] Incorrect error message thrown in some cases when returning result of == comparison in non-Bool-returning function

Previous ID	SR-51
Radar	None
Original Reporter	alexlew (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Environment

Mac OS X 10.11, Xcode 7.1

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 2323deb69c58b788d8842a67630d8d33

Issue Description:

In the (incorrect) code below, Swift produces a misleading error message. The error in the code is that we cannot return a Bool from a function that declares no return type. But Swift reports that the error is that the binary operator == cannot be applied to two values of type T.

// gives incorrect error message:
func areEqualValues<T: Equatable>(a: T, b: T) {
    return (a == b)
}

If we change the code slightly, we get the correct error message:

// gives correct error message
func areEqualValues<T: Equatable>(a: T, b: T) {
    let c = (a == b)
    return c
}

[SR-73] SILPasses/inline_recursive.swift failing on iOS Sim 32-bit

Previous ID	SR-73
Radar	None
Original Reporter	@bitjammer
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@bitjammer
Priority	Medium

md5: ea6e699cb4ddb0db3818658ca2efd713

Issue Description:

**************************************** TEST 'Swift :: SILPasses/inline_recursive.swift' FAILED ********************
Script:
--
/Users/david/repos/github/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/bin/swiftc -frontend -target i386-apple-ios7.0  -module-cache-path '/var/folders/7z/bwnqjmrs60b4bwxq7_4p3h540000gn/T/swift-testsuite-clang-module-cachegpOI9R' -sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk  -primary-file /Users/david/repos/github/swift/test/SILPasses/inline_recursive.swift  -parse-as-library -emit-sil -O | FileCheck /Users/david/repos/github/swift/test/SILPasses/inline_recursive.swift
--
Exit Code: 1

Command Output (stderr):
--
/Users/david/repos/github/swift/test/SILPasses/inline_recursive.swift:17:11: error: expected string not found in input
// CHECK: [[BUILTIN_INT:%.*]] = integer_literal $Builtin.Int64, 3
          ^
<stdin>:43:92: note: scanning from here
 %0 = function_ref @_TF16inline_recursiveP33_38E63D320CFF538A1F98BBC31453B1EB7recFuncFSiSi : $@convention(thin) (Int) -> Int // user: %3
                                                                                           ^
<stdin>:44:2: note: possible intended match here
 %1 = integer_literal $Builtin.Int32, 3 // user: %2
 ^

--

Looks like dc65f70 to me.

[SR-31] Test Driver/Dependencies/bindings-build-record.swift fails on OS X

Previous ID	SR-31
Radar	None
Original Reporter	tmandry (JIRA User)
Type	Bug
Status	Closed
Resolution	Done

Environment

OS X 10.11.1
swift commit e0e5257

Other output before failure:

--- Running tests for swift ---
--- check-swift-macosx-x86_64 ---
+ cd /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/stdlib/public/SwiftShims
+ /usr/local/Cellar/cmake/3.3.2/bin/cmake -E make_directory /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift
+ /usr/local/Cellar/cmake/3.3.2/bin/cmake -E create_symlink /Users/tyler/code/swift/build/Ninja-DebugAssert/llvm-macosx-x86_64/lib/clang/3.8.0 /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift/clang
+ /usr/local/Cellar/cmake/3.3.2/bin/cmake -E make_directory /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift/install-tmp/install-tmp
+ /usr/local/Cellar/cmake/3.3.2/bin/cmake -E remove /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift/install-tmp/install-tmp/clang
+ /usr/local/Cellar/cmake/3.3.2/bin/cmake -E create_symlink ../clang/3.8.0 /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift/install-tmp/install-tmp/clang
+ cd /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/test
+ /usr/local/Cellar/cmake/3.3.2/bin/cmake -E remove_directory /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./swift-test-results/x86_64-apple-macosx10.9
+ /usr/local/Cellar/cmake/3.3.2/bin/cmake -E make_directory /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./swift-test-results/x86_64-apple-macosx10.9
+ /usr/local/bin/python /Users/tyler/code/swift/llvm/utils/lit/lit.py -sv --xunit-xml-output=/Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/./swift-test-results/x86_64-apple-macosx10.9/lit-tests.xml /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64
lit.py: lit.cfg:211: note: using swift: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift
lit.py: lit.cfg:211: note: using swiftc: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swiftc
lit.py: lit.cfg:211: note: using swift-autolink-extract: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift-autolink-extract
lit.py: lit.cfg:211: note: using sil-opt: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/sil-opt
lit.py: lit.cfg:211: note: using sil-extract: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/sil-extract
lit.py: lit.cfg:211: note: using lldb-moduleimport-test: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/lldb-moduleimport-test
lit.py: lit.cfg:211: note: using swift-ide-test: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift-ide-test
lit.py: lit.cfg:211: note: using clang: /Users/tyler/code/swift/build/Ninja-DebugAssert/llvm-macosx-x86_64/bin/clang
lit.py: lit.cfg:211: note: using llvm-link: /Users/tyler/code/swift/build/Ninja-DebugAssert/llvm-macosx-x86_64/bin/llvm-link
lit.py: lit.cfg:211: note: using swift-llvm-opt: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift-llvm-opt
lit.py: lit.cfg:255: note: Using resource dir: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/lib/swift
lit.py: lit.cfg:281: note: Using Clang module cache: /var/folders/xl/kvdphsfj6230q3f8_m9h5zhw0000gn/T/swift-testsuite-clang-module-cacheVDw2y1
lit.py: lit.cfg:285: note: Using code completion cache: /var/folders/xl/kvdphsfj6230q3f8_m9h5zhw0000gn/T/swift-testsuite-completion-cacheyh0RpD
lit.py: lit.cfg:535: note: Testing OS X x86_64-apple-macosx10.9
lit.py: lit.cfg:614: note: Running tests on Mac OS X version 10.11.1 (15B42)
lit.py: lit.cfg:759: note: Using platform module dir: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/lib/swift/%target-sdk-name/x86_64
lit.py: lit.cfg:211: note: using sourcekitd-test: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/sourcekitd-test
lit.py: lit.cfg:211: note: using complete-test: /Users/tyler/code/swift/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/complete-test

Additional Detail from JIRA

Votes	3
Component/s
Labels	Bug
Assignee	tmandry (JIRA)
Priority	Medium

md5: b4c33156e31acff4d5ce4cbd74d5feb8

Issue Description:

I consistently get the following test failure when building from master (using

[SR-4] API availability checks are not implemented for non-Darwin platforms

Previous ID	SR-4
Radar	rdar://problem/18881232
Original Reporter	@jopamer
Type	Bug
Status	Reopened
Resolution

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: b127305c866f6c4eaeed6bc743b091bc

Issue Description:

We don’t have a good versioning scheme to use on non-Darwin platforms, so API availability checking always returns false on non-Darwin.

If nothing else, we should consider adding a compile-time warning or error when this language feature is used.

[SR-67] support gold as linker to build swift compiler on linux

Previous ID	SR-67
Radar	None
Original Reporter	ganadist (JIRA User)
Type	Improvement
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Improvement
Assignee	ganadist (JIRA)
Priority	Medium

md5: 643882fdd62b6ee0f284280ae9954f43

Issue Description:

I'm trying to compile swift on my archlinux box.
And I found that link step of swift compiler binary for debug build need lots of time.

In my case, ld command was running over 3 hours, but it could not complete link. and I could see ld consumed all system memories,

But after switched to gold, link step was completed in 3-4 minutes.

I'm using..
ArchLinux
binutils 2.25.1 (gold 1.11)
System Memory : 16Gb
Swap Memory : 16Gb

[SR-58] Problem building using bootstrapped ninja

Previous ID	SR-58
Radar	None
Original Reporter	dowobeha (JIRA User)
Type	Bug

Environment

Scientific Linux 7.1

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, BuildScript, Linux
Assignee	smikes (JIRA)
Priority	Medium

md5: d176f61f71c26cf8b306c2e254f2e055

Issue Description:

Failure to build when using a bootstrapped ninja.

Steps to reproduce:

• On Scientific Linux 7.1, install llvm, llvm-devel, clang, and cmake (version 2.8.11)

• Create new directory for swift repos, and in that directory, clone all swift-related repos from github, as per README.md in the swift repo

• In that same new directory, also clone ninja

• Run ./swift/utils/build-script

See also swift-users mailing list thread titled "Bootstrapping ninja and building from source" started on Fri, 4 Dec 2015.

Results of running ./swift/utils/build-script:

which: no ninja in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/lanes/.local/bin:/home/lanes/bin)
Building the standard library for: swift-stdlib-linux-x86_64
Running Swift tests for: check-swift-linux-x86_64

• rm -rf /home/lanes/swift/build/Ninja-DebugAssert/ninja-build
• cp -r /home/lanes/swift/ninja /home/lanes/swift/build/Ninja-DebugAssert/ninja-build
  ++ uname -s
• [[ Linux == \D\a\r\w\i\n ]]
• cd /home/lanes/swift/build/Ninja-DebugAssert/ninja-build
• python ./configure.py --bootstrap
  bootstrapping ninja...
  warning: A compatible version of re2c (>= 0.11.3) was not found; changes to src/*.in.cc will not affect your build.
  wrote build.ninja.
  bootstrap complete. rebuilding...
  [24/24] LINK ninja
  cmark: using standard linker
• cd /home/lanes/swift/build/Ninja-DebugAssert/cmark-linux-x86_64
• /usr/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ -DCMAKE_BUILD_TYPE:STRING=Debug /home/lanes/swift/cmark
  CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
  CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
  Missing variable is:
  CMAKE_C_COMPILER_ENV_VAR
  CMake Error: Could not find cmake module file:/home/lanes/swift/build/Ninja-DebugAssert/cmark-linux-x86_64/CMakeFiles/2.8.11/CMakeCCompiler.cmake
  CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
  Missing variable is:
  CMAKE_CXX_COMPILER_ENV_VAR
  CMake Error: Could not find cmake module file:/home/lanes/swift/build/Ninja-DebugAssert/cmark-linux-x86_64/CMakeFiles/2.8.11/CMakeCXXCompiler.cmake

• • Configuring incomplete, errors occurred!
    ./swift/utils/build-script: command terminated with a non-zero exit status 1, aborting