xTachyon wrote: That's pretty much what I was thinking of in terms of implementation.
> and we'd need the versioning information if we had Clang N tracking length + > contents and Clang N + 1 was tracking length + contents + encoding because > the newer Clang would be casting to a pointer of the wrong type if it was > given a CXString from the older Clang. > > But now that I think about it, this still runs into ABI issues like the > original solution. Newer Clang would produce a private_flags value that older > Clang couldn't handle gracefully. Does libclang support having different versions of it at the same time loaded in a process? Otherwise I don't see how the outside world would be able to tell or care what `data` and `private_flags` mean. In my suggestion, `StringWithLength` would only have a definition inside `CXString.cpp`; I don't want to make it part of the public API. I believe this would mean that this can be changed at any point for any reason. https://github.com/llvm/llvm-project/pull/134551 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
