Hi,
How do I tell which branch of llvm-project is used to build the Swift compiler? In particular which branch is being used to build the Swift 5.9 release.
The update-checkout tool uses a JSON file that lists exactly what branches are checked out for each repo: it lists swift/release/5.9 there from Apple's llvm-project fork. If you mean what upstream LLVM branch was used, I see that it used the Apple stable/20221013 branch when 5.9 was forked, so maybe that means upstream LLVM trunk was forked by Apple on that date?
Thanks. I guess I could have searched for "swift" in the number of branches, but there are so many
I'm just trying to see if a particular commit [lldb] Cherry-picks from upstream by medismailben · Pull Request #7104 · apple/llvm-project · GitHub has managed to make it into the 5.9 release. From what I can tell it hasn't and I would rather it didn't. It looks as if this commit breaks the integration between the VS Code Swift extension and the LLDB extension we are using, thus causing the debugger to crash.
I know this commit will eventually make it across, but if it doesn't appear in 5.9 it gives me more time to find a solution to the issue.
Stable/20221013 corresponds with the LLVM that Swift 5.9 uses. If the change is on that branch, then it will affect Swift 5.9.
Yes, the branch name format represents the date the branch was created.
So the commit I mention in my previous post will eventually be merged into release/5.9 as it doesn't appear to have been at the moment.
No, they’re separate repositories, stable/20221013 is the llvm portion of the Swift 5.9 compiler, and release/5.9 is the Swift portion. Changes to the llvm repository don’t merge into the Swift repository. If it’s on the llvm stable/20221013 branch now, it’s in the swift 5.9 compiler.
I think you misunderstood me I am talking about two branches in the llvm-project repository. According to update-checkout-config.json the release 5.9 build of Swift uses the branch swift/release/5.9 from llvm-project. This branch does not include the offending commit, while the stable/20221013 does include it.
That makes sense, as swift/release/5.9 was branched off of stable/20221013 in March, but the commit you are worried about was only merged into stable/20221013 three weeks ago and isn't in swift/release/5.9 yet, as your link shows. I don't know how long that will last though.
I don't know how long that will last though.
I said this because I didn't know how often Apple's stable/20221013 was merged back into swift/release/5.9, but diffing them now, the latter appears to be a proper branch with many less commits. So unless someone submits an lldb pull to get that commit into 5.9 now, it won't be there in that upcoming release, as you want.
The LLVM swift/release/5.9 branch is synced with Swift release/5.9, it automerges into stable/20221013, which is synced with Swift main.
The LLVM stable/20230725 branch is synced with Swift rebranch.
The LLVM next branch is synced with Swift next. It receives automerges from llvm.org main.
This is the current setup. The automerger configuration and branch setup changes a few times per year when new release branches get cut and qualified.
1 Like
This is correct.
Moreover, any LLDB commits need to be manually cherry-picked to the branches you want to land them on and next, because there is no automerger in that direction.
Thank you.
I'm not sure what the implications are for macOS and linux if the commit, I mentioned above, gets merged but I do know it broke debugging on VSCode Windows. We are looking at other solutions for Windows just now, which might be applicable to other platforms in the future.
Do you have a link to the commit you want to seen in 5.9?
Oh, is it [lldb] Cherry-picks from upstream by medismailben · Pull Request #7104 · apple/llvm-project · GitHub ?
No this is a commit I would rather not see merged into 5.9
I think I understand now 
This commit cleans up the SBAPI and that has unintended consequences for the vs_code plugin.
Yes, at least on Windows. I don't know enough about dynamic linking to know if it will be an issue on macOS and Linux.
@JDevlieghere @bulbazord @medismailben are probably the best people to discuss the path forward for the plugin with.
@adam-fowler The commit that was linked was originally authored by me but cherry-picked by @medismailben.
How did it break windows debugging exactly? Specific error messages would be helpful, but if my suspicions are correct you may need to rebuild something. I would prefer not to revert that commit if possible, but I'm open to talking about it depending on what's going on exactly.
Currently for debugging on VS Code we use an extension called CodeLLDB. It includes a debug adapter that uses the LLDB SB APIs to launch and manage debug sessions. We can use this along with the liblldb.dll that comes with the Windows Swift toolchain to get debugging of Swift.
If you build a Windows toolchain using latest which includes that commit. You now get the following errors when the CodeLLDB debug adapter launches
Error: "Could not load \"c:\\\\Users\\\\hiroshi\\\\.vscode\\\\extensions\\\\vadimcn.vscode-lldb-1.9.2\\\\adapter\\\\codelldb.dll\" (err=0000007F)" Debug adapter exit code=1 (0x1), signal=null.
This was tracked down to the lldb API change
6828:25a8 @ 419748421 - LdrpReportError - ERROR: Locating export "??0SBCommandInterpreter@lldb@@QEAA@PEAVCommandInterpreter@lldb_private@@@Z" for DLL "c:\Users\hiroshi\.vscode\extensions\vadimcn.vscode-lldb-1.9.2\adapter\codelldb.dll" failed with status: 0xc0000139.
You can find more details here A crash due to an lldb API change · vadimcn/codelldb · Discussion #976 · GitHub