[+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

Reply via email to