Re: [swift-dev] enquiry

On Fri, Dec 4, 2015 at 10:07 PM, Shaheen Sharafudheen wrote: > > hi, > i can't seem to verify the signature,here's what i get: > gpg: can't open `swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu15.10.tar.gz.sig' > gpg: verify signatures failed: file open error Hi Shaheen, Please verify that you have two f

[swift-dev] Starter project: SR-2: Build configuration directives can not wrap switch cases

Hi, If you're looking for a starter project in the frontend area (parser in this case), here is one. https://bugs.swift.org/browse/SR-2 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.swif

Re: [swift-dev] Verify failed

On Sun, Dec 6, 2015 at 9:08 AM, Piero Sabino via swift-dev wrote: > Yes, I've downloaded signature file and swift in the same directory. Could you post the actual error message, and SHA1 hashes of the files? Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/

[swift-dev] Starter project: Port Swift to RHEL 7 / CentOS 7 / Scientific Linux 7

Hi, RHEL 7 and CentOS 7 are widely used as server operating systems, and porting Swift to these distributions would benefit many community members. It should be relatively easy to do, since RHEL 7 is fundamentally another Linux system that uses the same basic libraries as other Linux ports we alr

Re: [swift-dev] Starter project: Port Swift to RHEL 7 / CentOS 7 / Scientific Linux 7

On Mon, Dec 7, 2015 at 10:25 AM, Meador Inge wrote: > On Mon, Dec 7, 2015 at 11:47 AM, Dmitri Gribenko via swift-dev > wrote: > >> Hi, >> >> RHEL 7 and CentOS 7 are widely used as server operating systems, and >> porting Swift to these distributions would benef

Re: [swift-dev] Continuous Integration on Swift.org projects

On Mon, Dec 7, 2015 at 12:49 PM, Brad Erickson via swift-dev < swift-dev@swift.org> wrote: > I'm hoping to get an ETA or learn the plan for enabling Continuous > integration on swift.org projects. It's listed as coming soon on the > website. Unit tests and builds are being broken by current untest

Re: [swift-dev] Starter project: Port Swift to RHEL 7 / CentOS 7 / Scientific Linux 7

On Mon, Dec 7, 2015 at 1:52 PM, Manolo van Ee wrote: > > >> On 07 Dec 2015, at 20:53, Dmitri Gribenko wrote: >> >>> On Mon, Dec 7, 2015 at 11:42 AM, Manolo van Ee >>> wrote: >>> I'd be happy to help out as well with Centos 7 if we can easily divide >>> tasks. Otherwise I can focus on Fedora, w

[swift-dev] Starter project: API to upgrade AnySequence to Any*Collection

Hi, If someone looks for a starter project in the standard library with intermediate complexity (prior experience with Swift generics required), here's one. This is in the area of existential sequence and collection wrappers. Upgrading AnyForwardCollection to AnyRandomAccessCollection works: (s

Re: [swift-dev] Starter project: API to upgrade AnySequence to Any*Collection

proposal, since it involves an API change? > > On Mon, Dec 7, 2015 at 2:08 PM, Dmitri Gribenko via swift-dev > wrote: >> >> Hi, >> >> If someone looks for a starter project in the standard library with >> intermediate complexity (prior experience with Swift gene

[swift-dev] Starter project: Initializers for converting UnsafePointers to integers

Hi everyone, The standard library has bitPattern initializers on pointers. But we are missing initializers to create integers from pointers. Someone needs to propose these APIs, walk them through swift-evolution, write a patch for the library and add tests. extension UInt { init(bitPattern: Un

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

Hi William, On Tue, Dec 8, 2015 at 8:00 PM, William Dillon via swift-dev < swift-dev@swift.org> wrote: > Hi all, > > I’ve been working on trying to get Swift to compile on ARMv7 (armv7l > specifically, not sure if other variants will work as well). I’ve gotten > pretty far, but I ran a cross an

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

On Wed, Dec 9, 2015 at 3:42 AM, Nick Wellnhofer via swift-dev wrote: > I guess this only works on 32-bit and needs another check for 64-bit. Why > isnt't `__swift_ssize_t` simply defined as `ssize_t`? This would avoid this > kind of problems. Because we can't include Glibc headers in SwiftShims.

Re: [swift-dev] Beginner's questions about building Swift from source etc.

On Wed, Dec 9, 2015 at 5:54 PM, Jordan Rose via swift-dev < swift-dev@swift.org> wrote: > Looks like Mish Awadah has an answer on a later thread: > >./swift/utils/build-script --preset="buildbot_osx_package" > install_destdir="${SWIFT_INSTALL_DIR}" > installable_package="${SWIFT_INSTALLABLE_PA

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

On Wed, Dec 9, 2015 at 3:05 PM, William Dillon via swift-dev wrote: > Nick was correct in noting that __muloti4 wasn’t needed on 32-bit platforms. > I added another case to the preprocessor conditional for __muloti4, and > specified __arm__ and __linux__ for mulodi4. The __multi3 and __divti3

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

On Wed, Dec 9, 2015 at 7:05 PM, Dmitri Gribenko wrote: > On Wed, Dec 9, 2015 at 3:05 PM, William Dillon via swift-dev > wrote: >> Nick was correct in noting that __muloti4 wasn’t needed on 32-bit platforms. >> I added another case to the preprocessor conditional for __muloti4, and >> specified

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

Here's a relevant line (there are lots, this is just one instance): 003a91cc 0015d403 R_ARM_REL32 003af914 _TMps13GeneratorType _TMps13GeneratorType ---> protocol descriptor for Swift.GeneratorType Dmitri On Wed, Dec 9, 2015 at 7:25 PM, William Dillon wrote: > I’m looking at that pull

Re: [swift-dev] Beginner's questions about building Swift from source etc.

On Thu, Dec 10, 2015 at 7:41 AM, Jens Persson wrote: > Thanks! > I tried the above to compile with the buildbot_osx_package preset. It kind > of worked, but it failed while performing the tests. > (TEST 'Swift :: Driver/Dependencies/bindings-build-record.swift' FAILED) > So, I got a working swiftc

Re: [swift-dev] program performance Ubuntu15.10 ?

On Thu, Dec 10, 2015 at 8:33 AM, Isaac Gouy via swift-dev wrote: > How should I compile Swift programs on Ubuntu 15.10 for best performance? > > Like this? > > >bin/swiftc -Ounchecked -whole-module-optimization > > > > What is performance with swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu15.10 > cu

Re: [swift-dev] preset: buildbot_linux_1404/1510 are the same

On Thu, Dec 10, 2015 at 10:33 AM, Brad Erickson via swift-dev wrote: > > The best solution is to remove one and rename the other simply: [preset: > buildbot_linux], but that will have far reaching effects. Nothing that can't > be dealt with though. How should this be handled? The best solution

Re: [swift-dev] Beginner's questions about building Swift from source etc.

Mish Awadah probably knows about setting up a custom toolchain in Xcode. Dmitri On Thu, Dec 10, 2015 at 9:44 PM, Jens Persson wrote: > Thanks again, > I pulled the latest Swift repos which included the fix of the failing test > and modified the build preset locally according to Dmitri's advice a

Re: [swift-dev] [stdlib] Array.description calls debugDescription on its contents

On Fri, Dec 11, 2015 at 1:38 PM, Wojciech Czekalski via swift-dev < swift-dev@swift.org> wrote: > Hi, > > while I was working on this PR > I encountered unexpected behavior from Array.description. It iterates > over its items and calls debugDescription on

Re: [swift-dev] [stdlib] Array.description calls debugDescription on its contents

On Fri, Dec 11, 2015 at 3:02 PM, Brent Royal-Gordon wrote: >>> while I was working on this PR I encountered unexpected behavior from >>> Array.description. It iterates over its items and calls debugDescription on >>> them. I found it a bit unexpected thus my question here. Is it desired >>> beh

Re: [swift-dev] Porting swift to FreeBSD

On Sat, Dec 12, 2015 at 8:29 PM, Davide Italiano via swift-dev wrote: > Hi, > I'm a FreeBSD developer who has been working on porting swift to FreeBSD. > I'm at a point where with a local patch ( > https://people.freebsd.org/~davide/swift/build_freebsd.diff ) to fix > build errors I'm able to buil

Re: [swift-dev] Porting swift to FreeBSD

On Sat, Dec 12, 2015 at 9:09 PM, Davide Italiano wrote: > On Sat, Dec 12, 2015 at 11:45 PM, Dmitri Gribenko wrote: >> On Sat, Dec 12, 2015 at 8:29 PM, Davide Italiano via swift-dev >> wrote: >>> Hi, >>> I'm a FreeBSD developer who has been working on porting swift to FreeBSD. >>> I'm at a point

Re: [swift-dev] Porting swift to FreeBSD

On Sat, Dec 12, 2015 at 9:26 PM, Davide Italiano wrote: > On Sun, Dec 13, 2015 at 12:22 AM, Dmitri Gribenko wrote: >> On Sat, Dec 12, 2015 at 9:09 PM, Davide Italiano >> wrote: >>> On Sat, Dec 12, 2015 at 11:45 PM, Dmitri Gribenko >>> wrote: On Sat, Dec 12, 2015 at 8:29 PM, Davide Italia

[swift-dev] Starter project: increase test coverage on Linux

Hi, Many important tests are XFAIL'ed on Linux. Usually this is because one or few parts of the test use the Objective-C runtime or rely on Foundation. These parts can usually be separated into separate files, or guarded with `#if _runtime(_ObjC)`. Sometimes these failures are real issues that we

Re: [swift-dev] Porting swift to FreeBSD

On Sun, Dec 13, 2015 at 2:52 AM, Davide Italiano wrote: > And now, swift compiled programs run correctly on FreeBSD! This is great, thanks Davide! > % ./swiftc hello.swift -o hello > davide@rabbit1:/exps/swift/build/Ninja-ReleaseAssert/swift-freebsd-x86_64/bin > % ./hello > hello > % cat hello.s

Re: [swift-dev] Running only one unit test through build-script?

On Sun, Dec 13, 2015 at 10:34 PM, Austin Zheng via swift-dev wrote: > Apologies if I'm overlooking something basic. I looked through the help for > both build-script and build-script-impl, and while I found flags to disable > parts of the prebuilt test suites, it doesn't look like there's a way

[swift-dev] Porting Swift to Linux aarch64 (arm64)

Hi, This weekend I have been playing with Swift on Linux on 64-bit arm. I have summarized my findings in this bug: https://bugs.swift.org/browse/SR-221 TL;DR: 20 tests fail in the main testsuite; there is an issue with type metadata, I'm thinking this is a linker issue. If someone would like t

Re: [swift-dev] Building on Fedora

On Sun, Dec 13, 2015 at 10:17 AM, Brad Erickson via swift-dev < swift-dev@swift.org> wrote: > I've got Swift building now on Fedora 23. > Hi Brad, Thank you for working on this! > The only problem issue I'm running into is probably related to: > https://llvm.org/bugs/show_bug.cgi?id=23785 > >

[swift-dev] Re-clone the cmark repository

Hi, We have made the swift-cmark repository an actual GitHub fork of the upstream cmark repository. When running build-script, you might see a message like this: You have an old copy of the cmark repository. You need to remove it and clone again: $ rm -rf /cmark $ /swift/utils/update-ch

Re: [swift-dev] Porting Swift to Linux aarch64 (arm64)

On Mon, Dec 14, 2015 at 3:16 PM, William Dillon wrote: > Thanks Dmitri, > > I’ve been reading cmake files all day, and noticing that some references to > the gold linker (specifically this one in cmake/modules/AddSwift): > > 1058 # Handle gold linker flags for shared libraries. > 1059 if(SWIFT

Re: [swift-dev] Porting Swift to Linux aarch64 (arm64)

Hi Will, I was using the binutils linker, not the gold one. Dmitri On Mon, Dec 14, 2015 at 2:19 PM, William Dillon wrote: > I’m on a limb here, but is it possible that the gold linker is causing > issues, or is it required? > > - Will > >> On Dec 13, 2015, at 11:45 PM

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

On Mon, Dec 14, 2015 at 5:57 PM, William Dillon via swift-dev wrote: > I’m still stuck on this after a while, but I’ve been paying attention to > other discussions (specifically the FreeBSD port), as well as reading tons of > code. One thing I noticed while writing up my observations on my blog

Re: [swift-dev] buildbot configuration + etc

+Mishal Awadah, Mishal Shah On Mon, Dec 14, 2015 at 8:04 PM, Travis Tilley via swift-dev < swift-dev@swift.org> wrote: > Is there any documentation somewhere on what the exact commands are that > the buildbot CI performs and how the packages on swift.org are created? > > I've noticed that: > > 1)

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

On Mon, Dec 14, 2015 at 11:20 PM, William Dillon wrote: > I built a very simple swift program (minimal hello world) using the arm > swiftc and the x86_64 swiftc, and had them emit the sil and llvm ir. The sil > it substantially similar between the toolchain tarball on swift.org and my > arm sw

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

On Tue, Dec 15, 2015 at 2:39 AM, Nick Wellnhofer via swift-dev wrote: > On 10/12/2015 00:05, William Dillon via swift-dev wrote: >> >> At this point, the compiler and standard library are all built, and I >> think I have one final issue. In the testing suite, the binaries generated >> by the swif

Re: [swift-dev] Building Foundation on FreeBSD

+Jordan for module issues. On Tue, Dec 15, 2015 at 10:55 AM, Davide Italiano via swift-dev wrote: > Hi, > I'm in the process of porting Foundation to FreeBSD (see > https://github.com/apple/swift-corelibs-foundation/pull/141). > After fixing a bunch of build/portability errors I'm now stuck tryin

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

On Wed, Dec 16, 2015 at 11:55 AM, William Dillon wrote: > Hi all, > > I think that I’ve found the culprit with linking errors on ARMv7-linux. I > was looking at the changes between the SwiftAndroid port, and I noticed an > extra flag they added in the AddSwift cmake module: -Wl,-Bsymbolic. I a

Re: [swift-dev] Starter project: SR-2: Build configuration directives can not wrap switch cases

On Thu, Dec 17, 2015 at 7:58 AM, Meador Inge wrote: > On Sun, Dec 6, 2015 at 5:04 PM, Dmitri Gribenko via swift-dev > wrote: > >> Hi, >> >> If you're looking for a starter project in the frontend area (parser >> in this case), here is one. >> >>

Re: [swift-dev] operator overloads

On Thu, Dec 17, 2015 at 11:20 AM, Rafkind, Jon via swift-dev wrote: > How does the Swift compiler determine which method or operator to call given > a set of overloads at a given call site? This question may conflate two > issues: method overloads and operator overloads, but it seems at least >

[swift-dev] Starter project: add stable sort to the standard library

Hi, The standard library should provide a stable sort. This needs a proposal to swift-evolution (the design should be trivial, new methods should mirror existing sorting APIs), and implementation. The standard library already contains an internal implementation of insertion sort, so implementing

Re: [swift-dev] Combining Skin Tone Emoji Into Single Extended Grapheme Clusters

Hi Michael, On Thu, Dec 17, 2015 at 9:16 PM, Michael Buckley via swift-dev < swift-dev@swift.org> wrote: > Hello, > > I would like to fix rdar://20511834 , which is that the new skin tone and > multi-person grouping emoji introduced with iOS 8.3 and OS X 10.10.3 are > represented as multiple exte

Re: [swift-dev] SIL/crashes/004-swift-expr-getsourcerange.sil

Thanks everyone for the investigation. I reproduced the issue and found that this test fails in the AST verifier, so I annotated it as such in https://github.com/apple/swift/commit/d9802dd59b0e98063ea57aa51435424dc8d304c7 . The buildbot_linux_1404 preset now works for me. Dmitri On Sat, Dec 19,

Re: [swift-dev] [swift-users] Cross Compiling Swift for Bare Metal?

On Sat, Dec 19, 2015 at 6:53 PM, Chaitanya Mannem via swift-users < swift-us...@swift.org> wrote: > Hi, > > > I wanted to know if it is possible to compile swift code for bare metal. I > know there is a runtime but does swift depend on it to execute even if I > don't use those features?, can I dis

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

+ Stephen Canon, because he probably has good ideas in this domain. On Fri, Dec 18, 2015 at 3:42 PM, Nadav Rotem via swift-dev < swift-dev@swift.org> wrote: > > *What’s next?* > > The small experiment I described above showed that compressing the names > in the string table has a huge potential f

Re: [swift-dev] [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

+ swift-dev, Jordan On Sun, Dec 20, 2015 at 2:21 AM, Dan Stenmark via swift-corelibs-dev wrote: > I'm trying to invoke Linux's unshare() system call from Swift, but without > much success. From C, it requires _GNU_SOURCE to be #define'd before the > #include . The Glibc module map does indeed

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

On Sun, Dec 20, 2015 at 9:43 PM, Nadav Rotem wrote: > > On Dec 20, 2015, at 2:17 AM, Dmitri Gribenko wrote: > > + Stephen Canon, because he probably has good ideas in this domain. > > On Fri, Dec 18, 2015 at 3:42 PM, Nadav Rotem via swift-dev > wrote: >> >> >> What’s next? >> >> The small experi

Re: [swift-dev] Compiler crash - relates to protocol and protocol extension

On Sun, Dec 20, 2015 at 4:42 AM, Jasl via swift-dev wrote: > Hi, > > I found a piece of code that could made the compiler crash, It’s can > reproduce on Xcode 7.2(7C68) with Apple Swift version 2.1.1 > (swiftlang-700.1.101.15 clang-700.1.81) Target: x86_64-apple-darwin15.2.0 > > the code is simpl

Re: [swift-dev] SwiftAndroid: Statically linking libicu and/or the stdlib?

On Mon, Dec 21, 2015 at 6:13 PM, Geordie Jay via swift-dev < swift-dev@swift.org> wrote: > ./utils/build-script -R --no-assertions -b -p --extra-swift-args > build-swift-static-stdlib=1 > This option builds static archives of the standard library, not a standard library that links in everythi

Re: [swift-dev] Combining Skin Tone Emoji Into Single Extended Grapheme Clusters

On Tue, Dec 22, 2015 at 12:10 AM, Michael Buckley via swift-dev < swift-dev@swift.org> wrote: > It actually appears that Swift already links against ICU. I'll see if I > can hook Swift up to ICU's grapheme separation code. > Hi Michael, Thank you for the investigation. Yes, calling into ICU for

Re: [swift-dev] LLDB Invalid address (32 bit arm)

+ swift-lldb-dev On Thu, Dec 24, 2015 at 3:03 PM, William Dillon via swift-dev wrote: > Hi all, > > I’m working on addressing issues that are preventing lldb from compiling on > 32-bit arm platforms. Many warnings are generated by the definition of > LLDB_INVALID_ADDRESS as UINT64_MAX. Ultima

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

On Wed, Dec 30, 2015 at 8:34 PM, Ling Wang via swift-dev wrote: > After reviewing the code of stdlib I found no one actually implements > _customContainsEquatableElement: > 1. Its default implementation in `SequenceType` just returns nil. > 2. The implementation in `Set` delegates to `contains` w

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

Yes, I think it is good -- this is exactly the use case for this method, except that @_transparent should be dropped, and the comment is duplicating the code, so it should be dropped, too. The change also needs a simple test that checks that calling .contains() on a suitable Range should dispatch

Re: [swift-dev] Current master is failing on 3 tests

+Nadav who committed these tests in 25832d39b22eb30370e7f1dc855e4919590f528f. On Thu, Dec 31, 2015 at 8:51 PM, Kevin Ballard via swift-dev wrote: > Running tests on current master fails on 3 tests every time. I already > checked to make sure I'm fully up-to-date. They reproduce with just > `bui

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

On Thu, Dec 31, 2015 at 10:06 PM, Ling Wang wrote: > Do you mean something like this in > validation-test/stdlib/SequenceType.swift.gyb: > > SequenceTypeTests.test("Range.contains/WhereElementIsComparable/dispatch") > { > MinimalComparableValue.timesLessWasCalled = 0 > let start = 0 > let

Re: [swift-dev] Swift vim support

On Thu, Dec 31, 2015 at 10:09 PM, Keith Smiley via swift-dev wrote: > Hey all, > > When swift was open sourced a few of us noticed that there was some existing > vim highlighting support[0]. While it sounds like what's there now hasn't been > kept up to date for a while[1], that brought up the que

Re: [swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

On Mon, Jan 4, 2016 at 6:50 PM, Todd Fiala via swift-lldb-dev < swift-lldb-...@swift.org> wrote: > > On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev < > swift-lldb-...@swift.org> wrote: > > Hi Todd, > > Yes, I think that LLDB is more or less working with Swift on ARM. We can > sta

Re: [swift-dev] Build Error: Relocation R_X86_64_PC32

On Mon, Mar 14, 2016 at 3:38 PM, Ryan Lovelett wrote: > On Tue, Mar 1, 2016, at 12:16 AM, Dmitri Gribenko wrote: >> IIRC there is no issue in the bug tracker, please feel free to file one! >> >> Also, if you are familiar with binutils internals, it might be helpful >> to bisect the linker. > > I'm

Re: [swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

On Mon, Mar 14, 2016 at 7:59 PM, Shawn Erickson wrote: > > > On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko > wrote: >> >> Hi everyone, >> >> I just wanted to announce that we have sufficient change on the >> swift-3-indexing-model branch so that we can build the core standard >> library and St

Re: [swift-dev] Cortex M0

On Tue, Mar 15, 2016 at 11:40 AM, Tanner Nelson via swift-dev wrote: > Hello Swift Dev, > > Does anyone know if it is possible to compile Swift 2.2 or 3.0 for the Cortex > M0? We have an ARMv6 port, but I believe the primary limitation you will run into is the code size and the required memory t

Re: [swift-dev] Cortex M0

On Tue, Mar 15, 2016 at 1:19 PM, Tanner Nelson wrote: > >> On Mar 15, 2016, at 4:11 PM, Dmitri Gribenko wrote: >> >> On Tue, Mar 15, 2016 at 11:40 AM, Tanner Nelson via swift-dev >> wrote: >>> Hello Swift Dev, >>> >>> Does anyone know if it is possible to compile Swift 2.2 or 3.0 for the >>> Co

Re: [swift-dev] Why no FloatingPointArithmeticType and DefaultInitializable protocols in stdlib?

Hi Jens, On Thu, Mar 17, 2016 at 6:36 PM, Jens Persson via swift-dev wrote: > Is there a reason why the standard library does not have a protocol like > IntegerArithmeticType but for floating point types? Improving numerics support in Swift is a part of a long-term plan. > Also, I don't know ho

Re: [swift-dev] Build Error: Relocation R_X86_64_PC32

On Tue, Mar 22, 2016 at 9:55 AM, Ryan Lovelett wrote: > I'd like to write this up as an issue, if one has not been created in > the 8-days it took me to get this working, is that a good idea or a bad > one? Thank you for the hard work! It is definitely a good idea to create a bug, I am not aware

Re: [swift-dev] large dictionary literal overflows swiftc stack

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev wrote: > I have to support swift 2.2 for the time being because I have to support the > current release of xcode. I will upgrade to swift 3 when it is released. I understand your motivation, but I would still recommend trying to update

Re: [swift-dev] Build errors

On Wed, Mar 23, 2016 at 9:11 AM, George King via swift-dev wrote: > Hello, > > In an effort to isolate a different bug, I'm trying to build HEAD of master, > and have encountered what looks to be a configuration error. Can somebody > please point me in the right direction? Hi George, Which bra

Re: [swift-dev] Error with SwiftGlibs building for arm-linux

On Thu, Mar 24, 2016 at 1:30 PM, Труб Илья wrote: > Dear colleagues > I have faced with strange behaviour, when I compile some swift source on > Ubuntu 14, target=arm-linux-gnueabi, all neccessary modules for arm present, > -sysroot and > -isysroot are passed via -Xcc. > > :61:10: note: in file

Re: [swift-dev] Error with SwiftGlibs building for arm-linux

On Thu, Mar 24, 2016 at 2:03 PM, Труб Илья wrote: > > Thanks for your answer, Dmitry. I will look for examples of module maps in > test sources. You shouldn't need to. If you have built Swift for arm, you should have the right one produced by the build system. How did you compile the standard

Re: [swift-dev] Error with SwiftGlibs building for arm-linux

Then you should have a module map for Glibc in the build products. Dmitri On Thu, Mar 24, 2016 at 2:32 PM, Труб Илья wrote: > I have built all targets for arm (including modules and libraries) within the > native arm environment on arm-emulator with chroot. > > 25.03.2016, 00:25, "Dmitri Griben

Re: [swift-dev] Requiring Xcode 7.3 to build Swift master for Apple platforms?

On Tue, Mar 29, 2016 at 11:29 AM, Andrew Hyatt via swift-dev wrote: > Agreed. The minimum OS X version for Xcode 7.3 is 10.11.0, which would make > El Capitan required to run Swift 3.0. Swift deploys back to OS X 10.9. We're only talking about developers. Dmitri -- main(i,j){for(i=2;;i++){fo

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #3818

Looks like it was https://github.com/apple/swift-corelibs-foundation/pull/286 Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/ ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

On Sun, Apr 3, 2016 at 2:11 PM, Brian Gesiak wrote: > I think #2 is the best option. It’s less work than both #1 and #3. I believe > logic like IsTestCandidate belongs in libIDE anyway—SourceKit should stick > to XPC and asynchronous communication with libIDE. I like #3 better (an option to swift

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

On Sun, Apr 3, 2016 at 4:53 PM, Brian Gesiak wrote: > My concern with adding a swiftc option would be deciding upon an interface > to it. Would we want something like clang-query--a generic method of finding > methods that match a set of criteria? That seems like it would be a lot of > work to imp

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

On Sun, Apr 3, 2016 at 7:56 PM, Brian Gesiak wrote: > Hmm... but then wouldn't that more tightly couple the test discovery tool > and the Swift compiler? In an earlier email you said you "like #3 better > [...] because that would decouple the test discovery tool from the Swift > compiler." I think

Re: [swift-dev] quick, spot the UB in this code:

On Wed, Apr 6, 2016 at 9:16 PM, Drew Crawford via swift-dev wrote: > and it should crash > deterministically if it gets non-terminated bytes, or It can't, how would you check for this, only given a pointer? > 2. It should not require null-terminated bytes This operation converts a C string to

Re: [swift-dev] quick, spot the UB in this code:

On Wed, Apr 6, 2016 at 9:54 PM, Daniel Dunbar wrote: > Could we get a method that takes a [UInt8] directly and performs the same > basic function? I think the root of the surprise here is that the compiler converts [UInt8] into an unsafe pointer. This is appropriate when the callee is a C API,

Re: [swift-dev] quick, spot the UB in this code:

On Wed, Apr 6, 2016 at 10:03 PM, Drew Crawford wrote: > > On Apr 6, 2016, at 11:51 PM, Dmitri Gribenko wrote: > > This operation converts a C string to a Swift string, so (2) is a > non-starter. > > > Then it is inappropriately named. The name of the constructor is > `validatingUTF8`, not `cStri

Re: [swift-dev] A type-checking performance case study

On Fri, Apr 8, 2016 at 11:47 AM, John McCall via swift-dev wrote: > I strongly recommend that we pursue declaration hiding as a language change. I completely agree with John. Not having this rule is not just a performance problem, it also leaks into the user model. For example: - If you have a

Re: [swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

On Mon, Apr 11, 2016 at 11:07 AM, Dave Abrahams wrote: > > on Sun Apr 10 2016, Austin Zheng wrote: > >> I'm really sorry for dropping the ball and disappearing off the list. I'd >> like >> to help out if I can. I'll check out the current branch tomorrow and see what >> the status of the work is,

Re: [swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

On Mon, Apr 11, 2016 at 3:16 PM, Dave Abrahams wrote: > > on Mon Apr 11 2016, Shawn Erickson wrote: > >> On Mon, Apr 11, 2016 at 11:42 AM Dave Abrahams wrote: >> >> on Mon Apr 11 2016, Shawn Erickson wrote: >> >> > Anything to attempt on strings? I see you are considering consolidating

Re: [swift-dev] What's the best way to handle failing SourceKit tests?

+Argyrios On Mon, Apr 11, 2016 at 7:55 PM, Michael Buckley via swift-dev wrote: > Hi, > > I'm currently working on SR-1115, adding initializers to Int and Uint to > convert from UnsafePointer, and after making my changes, the > SourceKit/DocSupport/doc_swift_module.swift tests are failing. (Failu

Re: [swift-dev] repl/test-repl-glibc.py Failure on Ubuntu

+Brian On Thu, Apr 14, 2016 at 2:46 PM, Ryan Lovelett via swift-dev wrote: > I've played around with `git bisect` and I think I've tracked it down to > this commit [1]. Which came from PR #1704 [2]. I've also updated the issue, > SR-1109, to include this information. > > c6121d56b19305cf59148d46a

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #4226

Right. The primary testsuite was not running since yesterday because of my build-script changes. Dmitri On Tue, Apr 19, 2016 at 12:22 PM, Greg Parker wrote: > Dmitri, your commit 265fa20c re-enabled tests that were previously not > running, correct? > > > On Apr 19, 2016, at 12:15 PM, no-re...

Re: [swift-dev] Importing .swift file into REPL?

On Wed, Apr 20, 2016 at 3:23 PM, Austin Zheng via swift-dev wrote: > Hello developers, > > Is there a way to import a .swift source file into the interactive REPL? > There are times I'd like to debug code by importing it into the REPL and then > typing in various interactive commands. However, c

Re: [swift-dev] Swift port to Windows : Offering help!

CC'ing Han, the maintainer of the Cygwin port. On Wed, Apr 20, 2016 at 10:59 PM, Joel Van Eenwyk via swift-dev wrote: > Hi all, > > I'm a very new user of Swift and interested in finding ways to contribute to > the project. I can happily work with the Linux port of the project, but I > have a lot

Re: [swift-dev] Help with SR-1052: Handling generic return values

+Doug, Joe On Tue, May 3, 2016 at 6:28 PM, Trent Nadeau via swift-dev wrote: > Can anyone help me with this? > > On Fri, Apr 22, 2016 at 6:43 PM, Trent Nadeau wrote: >> >> Could someone who knows the generics system better than I give me a >> pointer for my question in https://bugs.swift.org/bro

Re: [swift-dev] Why are we re-linking?

On Fri, May 6, 2016 at 9:16 AM, Jordan Rose wrote: > Hm. That might be a nice balance, and it’s not entirely a lie: that’s the > version of the compiler that you’re using, if not the stdlib and runtime. > I’d still like to put it behind a flag, so that we can turn it off it > certain configuration

Re: [swift-dev] Consider removing the space in Swift AST dump's "decl" attribute?

On Sun, May 8, 2016 at 8:22 PM, Minsheng Liu via swift-dev wrote: > Hi, > > I notice that currently the dumped AST contains a parsing-unfriendly “decl” > attribute like this: >> decl=fib.(file).func decl.b@fib.swift:4:9 Dumped AST is not meant to be machine parseable. The format is subject to ch

Re: [swift-dev] Consider removing the space in Swift AST dump's "decl" attribute?

On Mon, May 9, 2016 at 10:00 AM, Minsheng Liu wrote: > Thanks for your information. However, what I intend to work on is a > Swift-to-JS translator, which I guess probably need to stick with the > upstream anyway. I think that make the output a bit more parsing-friendly > will not harm, will it?

Re: [swift-dev] LazyFilterCollection is not a Collection

On Mon, May 9, 2016 at 11:46 AM, Rob Napier wrote: > It violates the performance requirements. > CollectionType.count requires O(1) access if Index is a > RandomAccessIndexType. Hi Rob, We don't have RandomAccessIndexType anymore. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

On Mon, May 9, 2016 at 7:35 PM, Brian Gesiak wrote: > Thanks for the feedback, everyone! > > Porting SourceKit to Linux seems like a reasonable solution to me. Still, > there are 354 lines of code in tools/SourceKit that reference "XPC", so a > Linux port will take more than a few lines of source

Re: [swift-dev] Cross-compiling (nearly) everything for RPi from OSX

On Mon, May 9, 2016 at 7:11 PM, Karl Wagner via swift-dev wrote: > Does anybody (or any bots) install directly from the build script? Yes, that's how all Swift builds are done. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/ ___ swift-dev mailing list

Re: [swift-dev] What do to when stdlib guidelines conflict with proposal?

On Wed, May 11, 2016 at 2:53 PM, Russ Bishop via swift-dev wrote: > I’m implementing SE-0017 but based on the standard library guidelines I think > Unmanaged should have initializers that take > UnsafePointer/UnsafeMutablePointer and vice-versa which would fit more > naturally with the way othe

Re: [swift-dev] Support for building without the stdlib

On Thu, May 12, 2016 at 1:07 PM, Vedant Kumar via swift-dev wrote: > Hi, > > I have a build preset which omits "stdlib;sdk-overlay" from > swift-install-components. > > After 6670bb76, this preset triggers a swift cmake failure (Unknown build > type). Is it no longer allowed to build swift witho

Re: [swift-dev] How to run the tests out-of-tree?

On Thu, May 12, 2016 at 6:33 PM, Karl Wagner via swift-dev wrote: > My original idea was a lot simpler - create a script grabbing the specific > executables we need (FileCheck, llvm-link, etc) and the tests, package it > up, ship it out via ssh and run it on the intended target, piping the output

Re: [swift-dev] How to run the tests out-of-tree?

On Thu, May 12, 2016 at 7:24 PM, Karl Wagner wrote: > I’m cross-compiling a native compiler. That is to say, I’m not building a > cross-compiler in the way we build for Android or iOS: a native compiler with > foreign standard libraries. Both the compiler and stdlib are foreign to the > build m

Re: [swift-dev] Argument unused warnings

On Tue, May 17, 2016 at 12:37 PM, Daniel Dunbar via swift-dev wrote: > Something broke yesterday causing Swift to report gobs of argument unused > warnings, see: > https://bugs.swift.org/browse/SR-1546 > for a reference. > > Does anyone know who this should go to? https://github.com/apple/swif

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #5285

Fixed. On Wed, May 25, 2016 at 2:40 PM, Daniel Dunbar via swift-dev < swift-dev@swift.org> wrote: > cmark is failing to build: > > cmark: using gold linker > + mkdir -p > /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/Ninja-ReleaseAssert/cmark-linux-x86_64 > + [[ -

[swift-dev] Please remove your Swift build directory

Hi, We have merged a CMake and build-script refactoring that requires a from-scratch build. Trying to use an existing build directory will result in strange errors in the middle of the build. Excuse me for the inconvenience. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/ __

Re: [swift-dev] Please remove your Swift build directory

On Tue, May 31, 2016 at 10:20 AM, Joe Groff wrote: > >> On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev >> wrote: >> >> Hi, >> >> We have merged a CMake and build-script refactoring that requires a >> from-scratch build. Trying to use

  1   2   >