Version of LLVM used by Swift

Thanks for the specifics. This makes sense to me -- I made that change with the intent of pruning the public interface of the SBAPI to stop exposing things that did not make sense to expose. At the time I had only considered the stability of the SBAPI in terms of the Itanium ABI -- mangled names do not encode the access level in them, so moving methods from public to protected or private have no effect as the exact same symbols are still around. After reading about Microsoft's mangling scheme it appears as though they do encode the access level into the name itself meaning that my change does break ABI on Windows. I apologize for the inconvenience here, it certainly was not my intention. LLDB tries very hard to avoid ABI breaks in its API. Usually changes to the SBAPI are purely additive -- No removals, no moving around, no changing return types or parameter types, no removing member fields of classes, etc. This prevents us from fixing mistakes after a new version of LLVM is cut, but it does mean that we guarantee some amount of backwards compatibility.

The good news is I don't think we'll need to move things from public to protected or private again the same way that my change did. As long as LLDB has a commitment to ABI stability, these kinds of events will be considered the exception rather than the norm. The bad news is that you cannot use the same lldb-vscode binary with the liblldb from the swift 5.8 toolchain and the swift 5.9 toolchain. You will need 2 separate binaries to be able to switch between them freely. It looks like the CodeLLDB maintainer is aware of this so I would follow-up with them to see where they are in that process.


Thanks Alex,

We are looking at different solutions from CodeLLDB at the moment..

One of those is using the lldb-vscode debug adapter that is included in the llvm project. This is already included in the Windows Swift toolchain and could be used to replace CodeLLDB. It is guaranteed to have been built using the same version of LLDB, as the rest of the toolchain.