Yikes! That's unsafe! When using withMemoryRebound, I think you're only supposed to use the argument $0 inside the block. Saving it and using it after withMemoryRebound is probably undefined behavior. But maybe you can move your ".pointee = x" into a separate function rather than using a closure?
On Sat, Sep 3, 2016 at 1:12 PM, Patrice Kouame via swift-users < swift-users@swift.org> wrote: > Finally Success! I’m seeing my pretty little 3D twirling Metal Renderer > cubes again… Here’s how > > Snippet of old sample code which no longer compiles in Xcode 8 beta 6 > with stricter Swift3 unsafe type casting restrictions > (in MetalView.swift from # Adopting Metal II: Designing and Implementing > a Real-World Metal Renderer) > > let shadowPtr = UnsafeMutablePointer<ShadowPass>(constantBufferForFrame. > contents()) > let mainPtr = UnsafeMutablePointer<MainPass>(shadowPtr.advanced(by: 1)) > mainPtr.pointee = mainPassFrameData > var ptr = UnsafeMutablePointer<ObjectData>(mainPtr.advanced(by: 1)) > > My conversion attempt that crashes Swift 3 Xcode 8 beta 6 (see RADAR 28150447 > - Swift 3 UnsafeMutablePointer conversion crashes the compiler and IDE) > > let shadowPtr = constantBufferForFrame.contents().bindMemory(to: > ShadowPass.self, capacity: MemoryLayout<shadowPassData>.size) > let mainPtr : UnsafeMutablePointer<MainPass> = shadowPtr.advanced(by: > 1).withMemoryRebound(to: MainPass.self, capacity: 1) { > $0.pointee = mainPassFrameData > } > var ptr : UnsafeMutablePointer<ObjectData> = mainPtr.advanced(by: > 1).withMemoryRebound(to: ObjectData.self, capacity: MemoryLayout< > ObjectData >.size) {$0} > > Latest conversion that make Xcode and Swift 3 smile again... > > let shadowPtr = constantBufferForFrame.contents().bindMemory(to: > ShadowPass.self, capacity: shadowPassData.count) > let mainPtr : UnsafeMutablePointer<MainPass> = shadowPtr.advanced(by: > 1).withMemoryRebound(to: MainPass.self, capacity: 1) {$0} > mainPtr.pointee = mainPassFrameData > var ptr : UnsafeMutablePointer<ObjectData> = mainPtr.advanced(by: > 1).withMemoryRebound(to: ObjectData.self, capacity: objectsToRender) {$0} > > Yes… Xcode/Swift3 SIL generation definitely did NOT like my "$0.pointee = > mainPassFrameData" statement. > Apparently, reassigning the pointee within the closure makes Swift gag out > of disgust. Sorry ;-( > That’s what I get for trying to be fancy… > And fixed my “capacity” issues thanks to some previous posters. > > Hope this helps anyone trying to get the Metal projects to compile again. > > At least I got a Radar out of this ;-) Compilers should never burn and > crash out like this... > > Regards to all, Patrice > > > On Sep 3, 2016, at 1:22 PM, Patrice Kouame via swift-users < > swift-users@swift.org> wrote: > > Gerard- > > Excellent! Looking forward to seeing your fix (hoping you get your book > back soon ;-) ) > > I think Xcode/Swift gags on the last ptr advance to objectData. I > recently tried another variant using withUnsafeMutablePointer like this: > > var ptr : UnsafeMutablePointer<ObjectData> = > withUnsafeMutablePointer(to: &mainPtr) { > $0.withMemoryRebound(to: ObjectData.self, capacity: > objectsToRender) { > $0.pointee = renderables[0].objectData > } > } > > ..but still crashes with no hints. > > My bug report also mentions that the Xcode migration/conversion tool is > incomplete. > It handles the “simpler" UnsafeMutableRawPointer<X> to > UnsafeMutablePonter<Y> with bindMemory cases correctly (one still has to > mind the capacity value though) > In all fairness, migrating/converting automagically in these cases is > always a little bit tricky - the proposed Xcode fixes should always be > reviewed by a human... > > Patrice > > On Sep 3, 2016, at 1:05 PM, Gerard Iglesias via swift-users < > swift-users@swift.org> wrote: > > Ok > > For the record I succeeded this transformation phase last week > > I remember the tedious stuff to advance pointer from one struct to the > other kind of struct... it worked > > But I don't have my MacBook with me, only the phone, the six :) > > Gérard > > Le 3 sept. 2016 à 18:22, Patrice Kouame <pkou...@me.com> a écrit : > > Indeed. There is a difference between stride and size, but I interpreted > capacity incorrectly for my purposes. It should indicate the number of <T> > elements (not their size - right?) and the snippets below should work. > > Still, compiler crashes and Xcode IDE is left in inconsistent state. So I > filed this Apple radar against Developer Tools. > > 28150447 - Swift 3 UnsafeMutablePointer conversion crashes the compiler > and IDE > Should I file a Swift bug too? Would that be helpful? > > Regards, Patrice > > On Sep 3, 2016, at 11:39 AM, Gerard Iglesias via swift-users < > swift-users@swift.org> wrote: > > Hello, > > I think that it is more secure to use stride in place of size, sometimes > it is not the same value. > > I use it in my own use of raw bindings > > Regards > > Gérard > > Le 3 sept. 2016 à 10:03, Patrice Kouame via swift-users < > swift-users@swift.org> a écrit : > > Hi Jacob - > > I think you’re right. “capacity” should be the count of type T elements in > my buffer. So in my case that line should read > > let shadowPtr = constantBufferForFrame.contents().bindMemory(to: > ShadowPass.self, capacity: shadowPassData.count) > > The withMemoryRebound calls need similar adjustments. The pointer to > MainPass is actually a single structure to it should be safe to do this > > let mainPtr : UnsafeMutablePointer<MainPass> = > shadowPtr.advanced(by: 1).withMemoryRebound(to: MainPass.self, capacity: 1) > { > $0.pointee = mainPassFrameData > } > > Whereas the unsafe pointer to <ObjectData> is actually a buffer of > renderable objects, so this should work: > > var ptr : UnsafeMutablePointer<ObjectData> = mainPtr.advanced(by: > 1).withMemoryRebound(to: ObjectData.self, capacity: objectsToRender) {_ in > } > > There are surely ways to refactor and simplify this, but I’m trying to > retain as much of the original sample code approach as possible. > > However, the compiler still segs badly. > Xcode also borks an internal error often. Only cleaning or restarting the > project can clear up that state. > Compilers (or Playgrounds for that matter) should never crash, and I’m not > sure where to file this bug : Swift or Apple radar against Xcode or both? I > now Xcode 8 is beta but…it’s been doing this for quite a while now... > > In both our “close to the metal” (no pun intended) cases, it seems like a > lot of churning for very little gain. Don’t you think? The easier, but > “unsafe” casting afforded previously did the trick with the normal caveats. > Don’t get me wrong, I love Swift and “get" all the neat type safety > features. Guess we can’t have our cake and eat it too, especially when > interfacing with “unsafe” C APIs. > > Anyway, back to rtfm … maybe some of the Swift Gods can chime in? ;-) > > I must be doing something stupid...Patrice > > On Sep 3, 2016, at 2:32 AM, Jacob Bandes-Storch <jtban...@gmail.com> > wrote: > > Hi Patrice, > I don't have a solution for you, but I just wanted to point out what I > think may be an error with your use of the new UnsafeRawPointer APIs: > > constantBufferForFrame.contents().bindMemory(to: ShadowPass.self, > capacity: MemoryLayout<ShadowPass>.size) > > I believe the `capacity` should actually be the number of ShadowPass > elements in the buffer, not the size of each element. Using `bindMemory(to: > ShadowPass.self` already implies that MemoryLayout<ShadowPass>.size is the > size of each element. > > More info at https://developer.apple.com/reference/swift/ > unsaferawpointer/2428875-bindmemory > > I just updated a small Metal project of mine to Swift 3. I ran into some > compiler (playground) crashes, but it does seem to work most of the time. > Although I only have 1 buffer :-) https://github.com/jtbandes/ > Metalbrot.playground > > Jacob > > On Fri, Sep 2, 2016 at 11:00 AM, Patrice Kouame via swift-users < > swift-users@swift.org> wrote: > >> Hi all - >> >> I’m converting Apple’s Swift Sample "Adopting Metal II: Designing and >> Implementing a Real-World Metal Renderer” in Xcode 8 beta6 to the latest >> UnsafeMutablePointer API for untyped memory access. >> Changes are necessary in MetalView.swift (Apple hasn’t updated their >> sample code for the latest beta yet…) >> The Swift Compiler crashes (Segmentation Fault: 11) on the attempt: >> >> // Grab a pointer to the constant buffer's data store >> // Since we are using Swift, it is easier to cast the pointer to >> the ShadowPass type to fill the constant buffer >> // We need to make a copy of these so the block captures the >> correct data >> >> // let shadowPtr = UnsafeMutablePointer<ShadowPas >> s>(constantBufferForFrame.contents()) >> let shadowPtr = constantBufferForFrame.contents().bindMemory(to: >> ShadowPass.self, capacity: MemoryLayout<ShadowPass>.size) >> shadowPtr.pointee = shadowPassData[0] >> >> //More Swift specific stuff - advance pointer and cast to >> MainPass >> >> // let mainPtr = UnsafeMutablePointer<MainPass>(shadowPtr.advanced(by: >> 1)) >> // mainPtr.pointee = mainPassFrameData >> let mainPtr : UnsafeMutablePointer<MainPass> = >> shadowPtr.advanced(by: 1).withMemoryRebound(to: MainPass.self, capacity: >> MemoryLayout<MainPass>.size) { >> $0.pointee = mainPassFrameData >> } >> >> //Advance and cast to ObjectData >> >> // var ptr = UnsafeMutablePointer<ObjectData>(mainPtr.advanced(by: >> 1)) >> var ptr : UnsafeMutablePointer<ObjectData> = >> mainPtr.advanced(by: 1).withMemoryRebound(to: ObjectData.self, capacity: >> MemoryLayout<ObjectData>.size) {_ in >> } >> >> let shadowOffset = 0 >> let mainPassOffset = MemoryLayout<ShadowPass>.size + shadowOffset >> let objectDataOffset = MemoryLayout<MainPass>.size + >> mainPassOffset >> >> // Update position of all the objects >> if multithreadedUpdate { >> DispatchQueue.concurrentPerform(iterations: objectsToRender) >> { i in >> let thisPtr = ptr.advanced(by: i) >> _ = self.renderables[i].UpdateData(ptr, deltaTime: 1.0/ >> 60.0) >> } >> } >> else { >> for index in 0..<objectsToRender { >> ptr = renderables[index].UpdateData(ptr, deltaTime: 1.0/ >> 60.0) >> } >> } >> >> ptr = ptr.advanced(by: objectsToRender) >> >> _ = groundPlane!.UpdateData(ptr, deltaTime: 1.0/60.0) >> >> Any help is appreciated. I have the latest Xcode log handy if >> necessary. Here’s a clip of the stack trace. >> >> 0 swift 0x000000010714a99d >> PrintStackTraceSignalHandler(void*) + 45 >> 1 swift 0x000000010714a3e6 SignalHandler(int) + 470 >> 2 libsystem_platform.dylib 0x00007fff91461bba _sigtramp + 26 >> 3 libsystem_platform.dylib 000000000000000000 _sigtramp + 1857676384 >> 4 swift 0x00000001047207b3 (anonymous >> namespace)::SILGenApply::visitExpr(swift::Expr*) + 51 >> 5 swift 0x0000000104723ace (anonymous >> namespace)::SILGenApply::visitApplyExpr(swift::ApplyExpr*) + 5182 >> 6 swift 0x0000000104711cc1 >> prepareApplyExpr(swift::Lowering::SILGenFunction&, swift::Expr*) + 273 >> 7 swift 0x00000001047624e7 >> swift::ASTVisitor<(anonymous namespace)::RValueEmitter, >> swift::Lowering::RValue, void, void, void, void, void, >> swift::Lowering::SGFContext>::visit(swift::Expr*, >> swift::Lowering::SGFContext) + 103 >> 8 swift 0x0000000104762313 >> swift::Lowering::SILGenFunction::emitExprInto(swift::Expr*, >> swift::Lowering::Initialization*) + 195 >> 9 swift 0x000000010474fbc3 >> swift::Lowering::SILGenFunction::emitPatternBinding(swift::PatternBindingDecl*, >> unsigned int) + 195 >> 10 swift 0x00000001047077bd >> swift::ASTVisitor<swift::Lowering::SILGenFunction, void, void, void, >> void, void, void>::visit(swift::Decl*) + 125 >> 11 swift 0x00000001047c0019 >> swift::ASTVisitor<(anonymous namespace)::StmtEmitter, void, void, void, >> void, void, void>::visit(swift::Stmt*) + 4169 >> 12 swift 0x00000001047809ba >> swift::Lowering::SILGenFunction::emitFunction(swift::FuncDecl*) + 314 >> 13 swift 0x00000001046fd775 >> swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl* >> )::$_1::operator()(swift::SILFunction*) const + 1877 >> 14 swift 0x00000001046fc322 >> swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*) + 626 >> 15 swift 0x00000001047c7007 (anonymous >> namespace)::SILGenType::emitType() + 1271 >> 16 swift 0x00000001047c6a9e >> swift::Lowering::SILGenModule::visitNominalTypeDecl(swift::NominalTypeDecl*) >> + 30 >> 17 swift 0x0000000104709093 >> swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, >> unsigned int) + 1795 >> 18 swift 0x000000010470ad4d >> swift::SILModule::constructSIL(swift::ModuleDecl*, swift::SILOptions&, >> swift::FileUnit*, llvm::Optional<unsigned int>, bool, bool) + 1629 >> 19 swift 0x00000001045621bf >> performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, >> llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*) + 19487 >> 20 swift 0x000000010455b2c5 >> swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, >> swift::FrontendObserver*) + 17029 >> 21 swift 0x000000010451888d main + 8685 >> 22 libdyld.dylib 0x00007fff91255255 start + 1 >> >> >> Patrice >> >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users >> >> > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > > > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users