Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 12, 2016, at 3:46 PM, Greg Parker wrote: >> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev > > wrote: >> >>> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev >> > wrote: >>> I just tracked down a bug due to C++ code in

Re: [swift-dev] Is SE-0138 UnsafeRawBufferPointer included in Xcode 8 beta 3?

Hi, I confirmed that the release notes has been fixed. Thanks! Norio Nomura @norio_nomura 2016-10-13 4:17 GMT+09:00 : > Hi, > > On behalf of Apple.. > > This is an error in the release notes. You’re not missing anything and > Swift in Xcode 8.1 beta 2 is the same as Xcode 8.1 beta 3. Sorry f

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev > wrote: > >> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev >> wrote: >> I just tracked down a bug due to C++ code in the Swift runtime code trying >> to interface with standard library code written in Swift, but getting the >

Re: [swift-dev] copy-on-write proposal

> On Oct 12, 2016, at 11:19 AM, Alexis via swift-dev > wrote: > > I’m having trouble figuring something out: is all of this contingent on all > of the relevant operations being completely inlined into a single function at > the SIL level? Could failing to inline a standard library function le

Re: [swift-dev] Is SE-0138 UnsafeRawBufferPointer included in Xcode 8 beta 3?

Hi, On behalf of Apple.. This is an error in the release notes. You’re not missing anything and Swift in Xcode 8.1 beta 2 is the same as Xcode 8.1 beta 3. Sorry for the confusion and we’ll get the release notes fixed up. Thanks, Ewa > On Oct 12, 2016, at 2:48 AM, Jens Persson via swift-de

Re: [swift-dev] copy-on-write proposal

> On Oct 12, 2016, at 11:19 AM, Alexis wrote: > > I’m having trouble figuring something out: is all of this contingent on all > of the relevant operations being completely inlined into a single function at > the SIL level? Could failing to inline a standard library function lead to > performa

Re: [swift-dev] copy-on-write proposal

I’m having trouble figuring something out: is all of this contingent on all of the relevant operations being completely inlined into a single function at the SIL level? Could failing to inline a standard library function lead to performance cliffs? I understand this is generally true of inlining

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev > wrote: > I just tracked down a bug due to C++ code in the Swift runtime code trying to > interface with standard library code written in Swift, but getting the ABI > slightly wrong and leading to some nasty hard-to-reproduce heisenbugs. W

Re: [swift-dev] copy-on-write proposal

Thanks for the feedback! Here is an updated version of the proposal: https://github.com/eeckstein/swift/blob/cow-proposal/docs/proposals/CopyOnWrite.rst (you can look at the history to see the changes compared

Re: [swift-dev] Is SE-0138 UnsafeRawBufferPointer included in Xcode 8 beta 3?

I'm wondering about this too. Xcode 8.1 beta 3 doesn't seem to include any of the pointer-related stuff mentioned in the release notes section New in Xcode 8.1 beta 3 - Swift Compiler. /Jens On Wed, Oct 12, 2016 at 2:13 AM, Norio Nomura via swift-dev < swift-dev@swift.org> wrote: > The release

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> getting the ABI slightly wrong Does this call for something like a validation pass? It would seem appropriate to apply it to SIL and not LLVM IR since it's inter-language ABI specific to Swift frontend. On Tue, Oct 11, 2016 at 8:17 PM, Daniel Dunbar via swift-dev < swift-dev@swift.org> wrote: