cask/quarantine: avoid xcrun when executing Swift

[Bo98]

Fixes things breaking when people put broken stuff into /usr/local/include:

• https://github.com/orgs/Homebrew/discussions/5170
• https://github.com/orgs/Homebrew/discussions/5109
• https://github.com/orgs/Homebrew/discussions/422#discussioncomment-257413

We were using /usr/bin/swift which is the same as /usr/bin/xcrun swift. This has a weird documented behaviour:

ENVIRONMENT
       CPATH
          This environment variable is modified by xcrun to include
          /usr/local/include when an explicit SDK is not requested via
          environment variable nor command line argument and neither -nostdinc
          nor -nostdsysteminc are present.

We can avoid this by using xcrun -find to find the underlying Swift executable and invoking that directly.

[apainintheneck]

This makes sense. Thanks for tracking this down. Do you have any idea why they added this unusual behavior to xcurn?

[apainintheneck]

It looks the old method returns a Pathname here but all the usages seem to just get coerced to strings so it's probably fine. On that note, it might be good to add types to this method.

Before:

brew(main):001:0> Cask::Quarantine.send(:swift)
=> #<Pathname:/usr/bin/swift>

After:

brew(main):001:0> Cask::Quarantine.send(:swift)
=> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift"

[Bo98]

Yeah maybe will keep it as a string because it's very slightly cheaper and is a private_class_method rather than API.

[Bo98]

Do you have any idea why they added this unusual behavior to xcurn?

My guess would be the transition from /usr/include to SDKs. Before it was very simple in that we had /usr/include and /usr/local/include. SDKs uses the sysroot system so that all these paths were prefixed with an SDK now, e.g. <sdk>/usr/include and <sdk>/usr/local/include. For compatiblity reasons it could make sense they made it so /usr/bin/clang worked like it did before with /usr/local/include.

That's just a theory though.

In any case, it hasn't scaled well with modules being introduced and generally with Swift. It makes some sense when working with Clang etc directly, but does raise a point that maybe this is something we want to avoid in the superenv, particularly on /opt/homebrew installs.

[MikeMcQuaid]

Makes sense, thanks again @Bo98!