Re: [swift-dev] Implementation of Type Erasers

On Mon, Sep 5, 2016 at 11:13 AM, Chris Eidhof via swift-dev wrote: > Hello swift-dev, > > I was wondering why type erasers (e.g. for AnyIterator) are implemented the > way they are. I would implement AnyIterator like this: > > final class MyAnyIterator: IteratorProtocol { > var nextImpl: () ->

Re: [swift-dev] Question about dump-ast and logging the output to file

On Wed, Aug 24, 2016 at 10:27 AM, Marcel Rebouças wrote: > Hello everybody, > > I am planning in doing some research and analysis with the ASTs of swift > programs and, for that reason, I am trying to modify the compiler to always > generate a file with the contents of the -dump-ast flag when buil

Re: [swift-dev] Standard Library not built in release mode with -R in build script

On Thu, Jul 21, 2016 at 8:35 AM, Ankit Agarwal via swift-dev wrote: > Standard library is not built in release mode by default with -R flag in > build script. Is that intended behaviour? > > Passing `--no-swift-stdlib-assertions --build-swift-static-stdlib > --swift-enable-ast-verifier=0` to build

Re: [swift-dev] Descriptive Protocol non-conformance errors

On Sun, Jul 17, 2016 at 7:41 AM, Sean Alling via swift-dev wrote: > Sorry for the late reply, > > Ted: > > A JIRA? I know that’s issue tracking, where can I get one of those? It is located here: https://bugs.swift.org/ . Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/ __

Re: [swift-dev] [swift-evolution] Endgame for Swift 3

On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev wrote: > Good question. > > Dave/Dmitri: do you have a recommendation here? I can see either the JIRA > issues referencing the proposal (if one exists) or updating the gist. I > prefer the former. Updating the JIRA sounds good to me,

Re: [swift-dev] Ubuntu 14.04 Swift master build failure

+ Michael, who has been working on CMake changes. On Sat, Jun 25, 2016 at 10:14 AM, Joseph Bell via swift-dev wrote: > Confirmed that I can reproduce this on my system (x86_64 Ubuntu14.04) : > build 1585 failed > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1585/ with > > CMake E

Re: [swift-dev] swift --version output changed

+ Michael, who has been working on CMake changes. On Sat, Jun 25, 2016 at 2:48 PM, Joseph Bell via swift-dev wrote: > Howdy, > > I noticed in a build today that the output of swift --version has changed. > Today's build: > > swift --version > Swift version 3.0-dev > Target: x86_64-unknown-linux-g

Re: [swift-dev] Standard shared libraries with executable stack

Thank you! I merged your PR, it should be included in the next snapshot. Dmitri On Fri, Jun 17, 2016 at 2:26 PM, Sangjin Han wrote: > Please review the PR #3053. > > 2016-06-18 0:17 GMT+09:00 Dmitri Gribenko : >> >> On Fri, Jun 17, 2016 at 7:31 AM, Sangjin Han >> wrote: >> > Hi, >> > >> > When

Re: [swift-dev] Standard shared libraries with executable stack

On Fri, Jun 17, 2016 at 7:31 AM, Sangjin Han wrote: > Hi, > > When linking libswiftCore.so, gold linker with --warn-execstack option > generates following messages. > /usr/bin/ld.gold: warning: lib/swift/linux/x86_64/swift_begin.o: missing > .note.GNU-stack section implies executable stack > /usr/

Re: [swift-dev] Standard shared libraries with executable stack

Hi, While there wight be an issue in WSL with executable stacks, Swift does not really need one. If the binary is actually asking for one, it would be great if we could figure out a way to ask the gold linker to not mark stacks as executable. Dmitri On Thu, Jun 16, 2016 at 11:39 PM, Sangjin Han

Re: [swift-dev] Standard shared libraries with executable stack

On Thu, Jun 16, 2016 at 5:17 AM, Jongsu Kim wrote: > Hi, > >> This could have been caused by our switch from the BFD linker to gold. >> Could you try linking a hello world program using gold linker and >> running it in WSL? > > > I tried to build Swift by not using -fuse-gold option and the result

Re: [swift-dev] Standard shared libraries with executable stack

On Sat, Jun 11, 2016 at 8:12 AM, 김종수 via swift-dev wrote: > I am testing Swift in "Windows Subsystem for Linux" which is a new feature > of Windows 10 Anniversary Update scheduled in this year. WSL is Ubuntu LTS > 14.04 compatible in user space. > > Swift runtime libraries such as libswiftCore.so

Re: [swift-dev] Delaying the enforcement of ".self" out of Swift 3?

On Thu, Jun 2, 2016 at 2:08 PM, Daniel Dunbar via swift-dev wrote: > As just a user of the language, as much as I hate churn I personally wouldn't > mind seeing this fixed. In this case, I think the laxness can make it harder > for developers to form the right mental model of the language; I kno

Re: [swift-dev] need help with GLibc module map problem

On Fri, Jun 3, 2016 at 8:23 AM, David P Grove wrote: > Dmitri Gribenko wrote on 06/02/2016 06:19:33 PM: >> >> Could you check if there are multiple definitions of off_t or mode_t >> in different headers guarded by macros? Something like this, >> duplicated across several headers: >> >> #if !defi

Re: [swift-dev] need help with GLibc module map problem

On Thu, Jun 2, 2016 at 2:58 PM, David P Grove via swift-dev wrote: > As part of helping to resolve old libdispatch pull requests, I have run into > a problem with the GLibc module map on Linux that I need help understanding > and fixing. > > The symptom I am trying to resolve is that somewhere bet

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

On Wed, Jun 1, 2016 at 12:36 PM, Austin Zheng wrote: > Hello, > > I'm still seeing errors when I try invoking the build script with `-x`. I've > updated all the repositories (everything that lives alongside the 'swift' > repo, as well as that repo itself) and deleted my build folder completely. >

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

On Wed, Jun 1, 2016 at 7:17 AM, Karl via swift-dev wrote: > We’d configure it like this: > - SWIFT_HOST_TRIPLE (e.g x86_64-unknown-linux-gnu) > - SWIFT_DEPLOYMENT_TARGETS (e.g. x86_64-unknown-linux-gnu + > armv7-linux-gnueabihf + armv7-none-linux-androideabi + > i386-none-linux-androideabi + …)

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

[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] [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 > + [[ -

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] 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] 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] 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] 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] 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] [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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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 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] [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] [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 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] [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] 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] 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] 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

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] 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] 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 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] 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] 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] 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] 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] 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] [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] 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] 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] 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?

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] 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] 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] 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] 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] 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] 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] [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

+ 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-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] 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] 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

[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] 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 >

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] [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] 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 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] [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] 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 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] 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] 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

[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] 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] 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] 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

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

[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 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

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 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] [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] [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] 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] 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] 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

  1   2   >