Drop references to clang-pseudo-gen after removal

[weliveindetail]

pseudo was removed from clang-tools-extra in upstream PR llvm/llvm-project#109154
Drop two explicit references in swift and unblock Windows CI

[weliveindetail]

@hjyamauchi @compnerd I think that will fix the Windows CI failures from these PRs:

• [lldb] Propagate SDKROOT env var in Shell tests on Windows llvm-project#9416 (comment)
• [cmake] Use Windows-specific LLDB test args on Windows llvm-project#9103 (comment)

[weliveindetail]

@bnbarham Last year you added the CMake option in swift_build_support/products/llvm.py. Do you see any use keep it, now that pseudo was removed? (If unsure I can leave out this half of the patch.)

[hjyamauchi]

@swift-ci please test

[bnbarham]

Do you see any use keep it, now that pseudo was removed? (If unsure I can leave out this half of the patch.)

I would have only added it to fix builds during rebranch, so if it was removed there shouldn't be any reason to keep it 👍. Though I'm confused this would fix anything as main is currently on stable/20230725. Rebranch is on stable/20240723 and that PR wouldn't be in there I believe.

EDIT: Oh you referenced a next PR. next isn't generally kept building for swift at all, so this is going to be the least of the problems.

[weliveindetail]

@hjyamauchi All tests have passed and this is ready to land. Can you merge please? Thanks

[bnbarham]

I'm still a little unsure of what you're trying to do here, but again, next is never going to pass today. We don't keep it building. For LLDB you'll want to target stable/20240723 (which matches rebranch in swift) and then cherry-pick to next (doesn't need to be passing, since again, it never will).

[weliveindetail]

@bnbarham Interesting, thanks for your note. Is that the general approach? Or only for the time until the rebranch is merged?

I would normally assume to go the other way around: land new patches on next and backport them to a stable branch.

[hjyamauchi]

As I understand, there's an auto-merger from upstream llvm to the next branch at all times (so that upstream merges will eventually arrive in next.) Most of the time, the development head / tip of tree is the (current)stable/XXXXXXXX and next will be the base for the next stable/XXXXXXXX when the next rebranch happens. We are currently in the process of transitioning from stable/20230725 to stable/20240723 but that hasn't completed yet. If you can wait for the rebranch to happen, then cherrypicking it to stable/20240723 would be sufficient. If you need it immediately, cherrypicking it to both stable/20230725 and stable/20240723 would make sense.

[bnbarham]

@bnbarham Interesting, thanks for your note. Is that the general approach? Or only for the time until the rebranch is merged?

If the change can be made upstream then the usual approach would be to do that and then cherry-pick to the stable branches. But for Swift-specific LLDB changes (which need to also compile the swift compiler) it's the other way around (stable -> next), as swift's next isn't kept green. CC @adrian-prantl / @JDevlieghere in case I'm giving bad advice there.

[shahmishal]

/bin/sh: /Users/ec2-user/jenkins/workspace/oss-swift-package-macos/build/buildbot_osx/llvm-macosx-arm64/bin/clang-pseudo-gen: Bad CPU type in executable

Going to revert this patch to unblock CI. https://ci.swift.org/job/oss-swift-package-macos/3546/changes#6437e32e2c6a9b1c7c1b423f7768e678574ea98f

[weliveindetail]

Well, this bot is building the same swift against llvm-project stable/20230725. That cannot work and I didn't know. Sorry for the noise.