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

Re: [swift-dev] Thread safety of weak properties

> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote: > #3 sounds like a great approach to me. I agree with Kevin that if we keep > the object husk approach that any use of a weak pointer that returns nil > should drop any reference to a husk. Spin locks are, unfortunately, illegal on iOS, which

[swift-dev] This little program currently compiles fine, but should it?

func ok() { let s = "see"; "Why are there exactly " 0 == 0 * 42 "warnings and errors in this code" let t = s + "?" print(t) } ok() // see? ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-de

Re: [swift-dev] This little program currently compiles fine, but should it?

Because currently only unused variable/constant declarations have warnings/fix-its attached to them. There have been some discussion on making non-void functions warn of unused results and it’s possible that this w

Re: [swift-dev] This little program currently compiles fine, but should it?

Yes, and I don't know if there is any particular reason why the == operator for Int doesn't have @warn_unused_result while the one for Doubles has: func f() { 1 == 2 } // OK func g() { 1.0 == 2.0 } // Warning: Result of call '==' is unused On Mon, Dec 14, 2015 at 7:40 PM, Johan Jensen wrote: >

Re: [swift-dev] Pointers vs. References?

> On Dec 12, 2015, at 4:20 PM, Michael Gottesman via swift-dev > wrote: > In general, we have not been particularly disciplined in this regard. I would > suggest following what is being done locally in the file you are modifying, > i.e. FuncDecl */TypeChecker & as per the LLVM style guide. The

Re: [swift-dev] Pointers vs. References?

I was thinking it might help some of the null-dereference issues if more things were to be passed as references. Is there a particular reason to use pointers instead? It seems there are several places which accept pointers and assume they're not null, which isn't really safe. (And, there's probabl

Re: [swift-dev] Thread safety of weak properties

> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev > wrote: > >> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote: >> #3 sounds like a great approach to me. I agree with Kevin that if we keep >> the object husk approach that any use of a weak pointer that returns nil >> should drop an

Re: [swift-dev] Pointers vs. References?

> On Dec 14, 2015, at 11:43 AM, Jacob Bandes-Storch wrote: > I was thinking it might help some of the null-dereference issues if more > things were to be passed as references. Is there a particular reason to use > pointers instead? It seems there are several places which accept pointers and > a

Re: [swift-dev] Porting swift to FreeBSD

> On Dec 12, 2015, at 8: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 where with a local patch ( >> https://people.freebsd.org/~david

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

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, Dmitri Gribenko via swift-dev > wrote: > > Hi, > > This weekend I have been playing with Swift on Linux on 64-bit arm. I > have summarized my findings in

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

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_ENABLE_GOLD_LINKER AND SWIFTLIB_SINGLE_SHARED) 1060 if("${SWIF

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, Dmitri Gribenko via swif

[swift-dev] Issues linking a C library module using swift build

Hello all, I’m having some strange issues on osx when trying to link a C library module. I’ve successfully did this before with another library, however, for some reason this one doesn’t work. My module map looks like this: module CFCGI [system] { header "/usr/local/include/cfcgi/cfcgi.h"

Re: [swift-dev] Issues linking a C library module using swift build

Auch, sorry, wrong list. Will repost in users. > On Tue 15 Dec, 15, at 02:30, Valentin Radu via swift-dev > wrote: > > Hello all, > > > I’m having some strange issues on osx when trying to link a C library module. > I’ve successfully did this before with another library, however, for some >

Re: [swift-dev] Issues linking a C library module using swift build

Can you post the output from: `swift build --clean && swift build -v`, thanks. > On Dec 14, 2015, at 4:30 PM, Valentin Radu via swift-dev > wrote: > > Hello all, > > > I’m having some strange issues on osx when trying to link a C library module. > I’ve successfully did this before with anoth

Re: [swift-dev] Issues linking a C library module using swift build

Sure: Cloning into '/Users/valentinradu/Playgrounds/April/Packages/libcfcgi'... warning: --depth is ignored in local clones; use file:// instead. done. /Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-01-a.xctoolchain/usr/bin/swiftc -module-name April -incremental -emit-dependencies -emit

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

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 http://www.housedillon.com/?p=2267 is that in stdlib/public/runtime/CMake

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] Proposal: Allow @objc(name) on enum declarations

(moved to swift-dev) I went ahead and implemented this over the weekend, but ran into some weird behavior when testing it. I defined a new macro # if defined(__has_feature) && __has_feature(generalized_swift_name) # define SWIFT_ENUM_NAMED(_type, _name, SWIFT_NAME) enum _name : _type # _name; enu

Re: [swift-dev] Thread safety of weak properties

On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote: > > > On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev > > wrote: > > > >> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote: > >> #3 sounds like a great approach to me. I agree with Kevin that if we keep > >> the objec

Re: [swift-dev] Thread safety of weak properties

> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev > wrote: > >> On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote: >> >>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev >>> wrote: >>> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote: #3 sounds li

Re: [swift-dev] Thread safety of weak properties

On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote: > > > On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev > > wrote: > > > >> On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote: > >> > >>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev > >>> wrote: > >>> >

Re: [swift-dev] Thread safety of weak properties

> On Dec 14, 2015, at 7:39 PM, Kevin Ballard wrote: > >> On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote: >> >>> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev >>> wrote: >>> On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote: > On Dec 14, 2015,

Re: [swift-dev] Thread safety of weak properties

> On Dec 14, 2015, at 3:19 PM, Greg Parker via swift-dev > wrote: > > >> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev >> wrote: >> >>> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote: >>> #3 sounds like a great approach to me. I agree with Kevin that if we keep >>> the object h

[swift-dev] buildbot configuration + etc

per/Toolchains/swift-2.2-SNAPSHOT-2015-12-14.xctoolchain > \ > > install_symroot=/Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-14/ > \ > symbols_package=/tmp/swift-symbols.tar.gz \ > darwin_toolchain_bundle_identifier=org.swift.20151214 \ > darwin_

[swift-dev] Breaking change in lexing operators next to comments

Hi all, I’m investigating this bug: https://bugs.swift.org/browse/SR-186 Which appears to be a result of the fact that the logic that determines if an operator is prefix/postfix/binary does not treat comments as whitespace. So, for example: /* comment */!foo does not lex as expected because t

Re: [swift-dev] buildbot configuration + etc

\ >> >> install_symroot=/Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-14/ >> \ >> symbols_package=/tmp/swift-symbols.tar.gz \ >> darwin_toolchain_bundle_identifier=org.swift.20151214 \ >> darwin_toolchain_display_name=20151214 \ >> darwin_toolc

Re: [swift-dev] buildbot configuration + etc

itive. >> >> 2) The buildbot presets don't have sane defaults and I can't find any >> documentation on what "sane" might mean for those builds. >> >> 3) I still can't build the full suite using the following command (which, >> again,

Re: [swift-dev] Proposal: Allow @objc(name) on enum declarations

> On Dec 14, 2015, at 6:52 PM, Kevin Ballard wrote: > > (moved to swift-dev) > > I went ahead and implemented this over the weekend, but ran into some weird > behavior when testing it. I defined a new macro > > # if defined(__has_feature) && __has_feature(generalized_swift_name) > # define

Re: [swift-dev] Breaking change in lexing operators next to comments

> On Dec 14, 2015, at 8:15 PM, Jesse Rusak via swift-dev > wrote: > > Hi all, > > I’m investigating this bug: https://bugs.swift.org/browse/SR-186 > > > Which appears to be a result of the fact that the logic that determines if an > operator is prefix/

Re: [swift-dev] Breaking change in lexing operators next to comments

It seems to make more sense to treat comments as this if they are not present. As a related question, should the presence/absence of whitespace be important at all? It seems fragile if it is. -Simon > On 14 Dec 2015, at 9:42 PM, Chris Lattner via swift-dev > wrote: > >> >> On Dec 14, 2015,

Re: [swift-dev] Breaking change in lexing operators next to comments

If you treat comments as though they are not present, you can no longer reason locally about whitespace on either side of an operator. Straw example: foo/* insert an excerpt from War and Peace here */! I need to scan to the other side of the comment to determine if ! is preceded by whitespace.

Re: [swift-dev] Thread safety of weak properties

On Mon, Dec 14, 2015, at 07:48 PM, Greg Parker wrote: > > > On Dec 14, 2015, at 7:39 PM, Kevin Ballard wrote: > > > >> On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote: > >> > >>> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev > >>> wrote: > >>> > On Mon, Dec 14, 2015, at

Re: [swift-dev] Proposal: Allow @objc(name) on enum declarations

On Mon, Dec 14, 2015, at 09:34 PM, Douglas Gregor wrote: > >> On Dec 14, 2015, at 6:52 PM, Kevin Ballard wrote: >> >> (I haven't touched case prefix stripping; presumably it's trying to >> strip the Swift name instead of the ObjC name) > > Probably. It’s not actually clear which prefix it should t

Re: [swift-dev] Breaking change in lexing operators next to comments

> On Dec 14, 2015, at 9:51 PM, Simon Pilkington > wrote: > > It seems to make more sense to treat comments as this if they are not present. > > As a related question, should the presence/absence of whitespace be important > at all? It seems fragile if it is. The current design depends on whi

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

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 swiftc, except that the arm version has a few sil_vtable, NSArray,

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] Proposal: Allow @objc(name) on enum declarations

Sent from my iPhone > On Dec 14, 2015, at 10:59 PM, Kevin Ballard wrote: > >> On Mon, Dec 14, 2015, at 09:34 PM, Douglas Gregor wrote: >> >>> On Dec 14, 2015, at 6:52 PM, Kevin Ballard wrote: >>> >>> (I haven't touched case prefix stripping; presumably it's trying to strip >>> the Swift