[+swift-dev] We're fine with the type not being 'void *' exactly, but we have been checking that it's pointer-sized (see ImportDecl.cpp's getSwiftStdlibType). I think you can probably get away with just dropping that specifically on non-Darwin AArch64 as long as you provide a custom implementation of CVaList"Pointer" that makes sense.
Now, the next level of complexity, which fortunately doesn't apply to your arch: why is it called "CVaListPointer" and not just CVaList? Because sometimes va_list is an array, which means it can mean different things in a parameter list vs. elsewhere. (This occurs on non-Darwin x86_64 <https://www.uclibc.org/docs/psABI-x86_64.pdf>.) The specific case I can think of is someone embedding a va_list in a struct, for whatever reason. CVaListPointer won't do the right thing there, since we're defining it explicitly in Swift to be pointer-sized. That said, I don't care about this case directly; as long as we don't try to import such a field as a CVaListPointer, it's okay. (It'll probably be imported as 'va_list', which is unfortunately confusing, but it won't come up much.) So, once you've lifted the pointer-size restriction, we could consider renaming CVaListPointer to CVaList or something else (deprecating the old name), in light of the fact that it's not pointer-sized everywhere. This would require going to swift-evolution, though. Jordan > On Oct 17, 2017, at 10:54, Saleem Abdulrasool <compn...@compnerd.org> wrote: > > Hey Jordan, > > So, it seems that on AArch64, the va_list type is a structure, and larger > than a void *. It seems that this prevents the importer from mapping the > type into the swift representation. I was wondering if you had any > suggestions on how to best handle this. > > Thanks! > > Saleem > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
