Re: [swift-dev] RFC: Better diagnostics through simplification

> On Aug 24, 2017, at 00:08, John McCall wrote: > >> >> What do people think? The meat of the change is tiny and below. The vast >> majority of the work is the long and painful fallout in the test suite, >> which I’m cautiously (and perhaps foolishly) stepping up to doing. > > I think that’s

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

This should fix itself in the next build. -- adrian > On Aug 24, 2017, at 9:50 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#242] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/242/ >

[swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

I've found what I believe is a bug. Though I'm unclear if the bug is in Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is quite drastically different between the two. For the code below (and attached): import Cocoa var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41,

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev > wrote: > > I've found what I believe is a bug. Though I'm unclear if the bug is in > Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is > quite drastically different between the two. > > For the code below (and at

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

Is there a radar or bugs.swift.org ticket filed on this? I presume because of the import this is a Darwin thing and not a linux thing. > On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev > wrote: > > >> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev >> wrote: >> >> I

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

I see the issue.. the latest version traps (appropriately so). let str = String(bytes: data[0..<2], encoding: .utf8)! The sub-range of the slice you have is incorrectly indexed. Try this out (I am presuming this is what you mean): let str = String(bytes: data[data.startIndex..<(data.startIndex

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

I think your onto it Philippe but then why is it behaving that way? I updated my earlier script (attached) and added 2 things. 1. print("Start: \(data.startIndex), End: \(data.endIndex), Count: \(data.count)") after the data.removeFirst(4). 2. The startIndex offset you suggested. It no

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

This is expected behaviors of collections and their slices. The previous result was a bug. I agree that collections in general and their slices need more documentation. Sent from my iPhone > On Aug 24, 2017, at 11:28 AM, Ryan Lovelett > wrote: > > I think your onto it Philippe but then why i

Re: [swift-dev] swift module format

Hi, What are you trying to do exactly ? Have you considered reading the decls with a tool using the C++ APIs (load a module and iterate over the decls) ? I think that would be easier and more future-proof. > On Aug 22, 2017, at 11:57 AM, Coder via swift-dev wrote: > > Hello, > > I’m working o

Re: [swift-dev] swift module format

Yeah, it’s important to keep in mind we don’t have a stable module format right now, so anything developed Swift 4 will likely need to be revised again with the next version. The C++ API is not stable either, but approach could be to dump the ‘generated interface’ using swift-ide-tool or simila

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

I think this is a transient failure because my patch changed ABI — can someone clean the workspace? > On Aug 24, 2017, at 6:17 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#254] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-li

Re: [swift-dev] swift module format

I’m working on a swift target for haxe and want it to use the interfaces in swift modules. The haxe compiler is written in ocml and so far I’ve created an llvm bitcode parser in ocaml which can read all the blocks and records, then read through the DECLS_AND_TYPES_BLOCK and map DECLS to their pa

Re: [swift-dev] swift module format

> On Aug 25, 2017, at 1:41 AM, Coder via swift-dev wrote: > I’m working on a swift target for haxe and want it to use the interfaces in > swift modules. The haxe compiler is written in ocml and so far I’ve created > an llvm bitcode parser in ocaml which can read all the blocks and records, > th

Re: [swift-dev] swift module format

> On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev > wrote: > > Or if you really want to avoid the FFI, you could take our current ASTDumper > output, which is currently pseudo-machine-readable, and make it actually > machine-readable. The elegant approach there would be to take the e

Re: [swift-dev] swift module format

> On Aug 25, 2017, at 2:34 AM, Slava Pestov wrote: >> On Aug 24, 2017, at 10:56 PM, John McCall via swift-dev > > wrote: >> >> Or if you really want to avoid the FFI, you could take our current ASTDumper >> output, which is currently pseudo-machine-readable, and make