Re: [swift-dev] Build and install custom toolchain?

I filed a ticket for making such a script as https://bugs.swift.org/browse/SR-174. I'm not filing one for the install path at the moment, since that appears to be configurable in the code you provided (your code is just hardcoding the install dir as inside of Xcode). -Kevin On Wed, Dec 9, 201

Re: [swift-dev] Build and install custom toolchain?

It does help, thanks. I'm surprised there's no script (or option to build-script) to do this automatically. Seems like a reasonable thing to want to do upon occasion. Also, I assume that those of us who aren't at Apple probably don't want to be using /Applications/Xcode.app/Contents/Developer/T

[swift-dev] problems with linking .tbd frameworks in test suite

Hi all, Apologies if this is not the right place to ask this. I built Swift successfully today, but was failing lots of tests because the linker couldn't find CoreFoundation (or other frameworks, including libsystem and libobjc). It looks like ld was invoked with the arguments: -syslibroot /Ap

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] [SR-40] Port Swift to Arm progress / question

I’m looking at that pull request currently, thanks for the link.Here is the output of readelf -r for libswiftcore, test.swift (as compiled) and test.swift.Thanks for looking into this!- Will relocatable.tar.bz2 Description: BZip2 compressed data On Dec 9, 2015, at 7:14 PM, Dmitri Gribenko

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] Question about implementation of closure capture lists

> On Dec 9, 2015, at 2:39 PM, Chris Lattner wrote: > >> >> On Dec 9, 2015, at 8:57 AM, Greg Titus via swift-dev >> wrote: >> >> Hi all, >> >> I thought I’d take a look at SR-153 "Bad fix suggestion for changing value >> of capture list constants" , and

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

[swift-dev] SILVerifier: Should SuperMethodInst's result type be the same type as the referenced member?

[Joe, Roman, sorry for resend, I got the e-mail group wrong] In SuperMethodInst's verifier, we have: require(CMI->getType() == TC.getConstantType(CMI->getMember()), "result type of super_method must match type of method"); I think this assumption was valid when we only allowed super_metho

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

Looks like Mish Awadah has an answer on a later thread: > Here’s what I’ve done in the past to build a toolchain using the build > script. > > function build_osx_package() { > >YEAR=$(date +"%Y") >MONTH=$(date +"%m") >DAY=$(date +"%d") >TOOLCHAIN_VERSION="swift-SNAPSHOT-${YEAR}

Re: [swift-dev] Radar and bugs.swift.org

> On Dec 9, 2015, at 5:21 PM, Frederick Kellison-Linn via swift-dev > wrote: > > Hi everyone, > > All throughout the Swift codebase there references to Radar bugs (just do a > search for “rdar" on the repo). As far as I am aware, these are all still > private/internal. Is this the case? Yes

Re: [swift-dev] Build and install custom toolchain?

Hi Kevin, Here’s what I’ve done in the past to build a toolchain using the build script. function build_osx_package() { YEAR=$(date +"%Y") MONTH=$(date +"%m") DAY=$(date +"%d") TOOLCHAIN_VERSION="swift-SNAPSHOT-${YEAR}-${MONTH}-${DAY}-a" ARCHIVE_DIR="${TOOLCHAIN_VERSION}-${B

[swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

In order to write textual SIL -> SIL testcases that exercise the handling of debug information by SIL passes, we need to make a couple of additions to the textual SIL language. In memory, the debug information attached to SIL instructions references information from the AST. If we want to create

Re: [swift-dev] Starter project: Remove old mirrors

Thanks for sharing that, Slava! Reading that really helped me gain a better understanding of how the current reflection model works and how it could be extended. Although my intended use cases are more for in-process type-level reflection akin to objc_copyClassList and class_copyPropertyList. In

Re: [swift-dev] Question about implementation of closure capture lists

> On Dec 9, 2015, at 8:57 AM, Greg Titus via swift-dev > wrote: > > Hi all, > > I thought I’d take a look at SR-153 "Bad fix suggestion for changing value of > capture list constants" , and I’d > really appreciate it if someone more familiar with the cod

[swift-dev] Build and install custom toolchain?

Is there an easy way to build and install my own toolchain into /Library/Developer/Toolchains? I assume there must be some automated way to construct the package installer, but nothing immediately leaps out at me. It looks like build-script can create a root, but that seems to be for BNI, which

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

Hi all, First of all, sorry for not being able to formulate these presumably basic questions in a better/shorter way. Background: We're working on an app that will benefit greatly from Swift's ability to generate optimized code from relatively high level abstractions. I've successfully compiled

Re: [swift-dev] Determining if a crash is a known issue?

> On Dec 9, 2015, at 1:56 PM, Kevin Ballard via swift-dev > wrote: > > When I get a crash in Swift, is there any easy way to figure out if it's > already a known crasher? Not that I know of. > I know there's a bunch of test cases in > validation-test/compiler_crashers{,_2}/ which I assume

[swift-dev] Determining if a crash is a known issue?

When I get a crash in Swift, is there any easy way to figure out if it's already a known crasher? I know there's a bunch of test cases in validation-test/compiler_crashers{,_2}/ which I assume are all existing crashers. Short of reading through them for similar-looking code, is there some solut

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] Inconsistent trapping for Bit

Mind filing a but at bugs.swift.org ? Is is the documentation on one of Index protocol you are referring to? max > On Dec 8, 2015, at 7:31 PM, Patrick Pijnappel via swift-dev > wrote: > > Swift.Bit traps for Bit.One.successor(), but not for Bit.One.advancedBy(1). > >

Re: [swift-dev] Proof-of-concept port of Swift for Android

> On Dec 8, 2015, at 8:57 PM, Chris Lattner via swift-dev > wrote: > > On Dec 8, 2015, at 8:50 PM, Zhuowei Z via swift-dev > wrote: >> I'm currently working on adding support to the Swift compiler to allow it to >> target Android. > > Cool. Responding to one spec

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

> On Dec 9, 2015, at 10:05 AM, Nick Wellnhofer via swift-dev > wrote: > > On 09/12/2015 18:55, Nick Wellnhofer via swift-dev wrote: >>> Is there a better way to get that symbol, and why wasn’t this a problem for >>> x86_64? >> >> AFAICS, this is a problem for x86_64 Linux. It's not a problem o

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

On 09/12/2015 18:55, Nick Wellnhofer via swift-dev wrote: Is there a better way to get that symbol, and why wasn’t this a problem for x86_64? AFAICS, this is a problem for x86_64 Linux. It's not a problem on Apple platforms, because there C++ binaries are linked with compiler-rt instead of the

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

On 09/12/2015 18:43, William Dillon via swift-dev wrote: I have no intention of addressing every issue here, but there is another I have a question about while I’m at it. While linking Swift.o, there is an undefined reference to __mulodi4. I found that __muloti4 is copied from compiler-rt int

[swift-dev] Question about implementation of closure capture lists

Hi all, I thought I’d take a look at SR-153 "Bad fix suggestion for changing value of capture list constants" , and I’d really appreciate it if someone more familiar with the code could check my thoughts, rather than me jumping straight to submitting a pull

Re: [swift-dev] Allowing extensions of bound generic types

Email is hard...last sentence should say "in the case of extensions". Jacob ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev