| 1 Dec 2025 |
 samasaur | my impression is that since the SDK rework, maintaining a specific version of the SDK is not inherently difficult, and all the actual challenges come from packages using that SDK | 17:42:33 |
 Randy Eckenrode | We could keep the version information around but not provide the attribute. Swift could build with a special stdenv using that SDK. | 17:44:52 |
| samasaur | yeah that's kinda what im thinking | 17:45:14 |
| samasaur | bc a new SDK version is just a URL and hashes, right? | 17:45:32 |
| Randy Eckenrode | The major version is an argument to the SDK derivation. We would just need to keep the old SDK version files around for that. | 17:46:57 |
 emily | I don't think we should have to rely on that kind of thing. I think we should just report this issue to upstream before planning for that… | 17:48:12 |
| emily | there's no reason the bootstrap compiler couldn't digest macro definitions and then simply error out if they are ever used, right? | 17:48:33 |
| emily | all we need is that the Swift macro machinery itself can be built without using stuff that uses macros – which is already a property they have to maintain by definition | 17:48:55 |
| Randy Eckenrode | I don’t think upstream intends Darwin to be bootstrapped this way. | 18:00:51 |
| Randy Eckenrode | It’s simply not a supported feature. As soon as the parser hits a macro definition, it bails. | 18:02:04 |
| emily | it doesn't seem like it should be hard to keep working, right? the macro machinery presumably already doesn't use much OS-specific stuff / fancy Swift features, so it's unlikely that any macros in the SDK will truly be required to build enough to process them | 18:04:55 |
| emily | right, what I mean is that they could simply defer that error to the use site, for the bootstrap compiler | 18:05:09 |
| emily | it seems very cheap to just report and see if they care or not | 18:05:20 |
| emily | if it was working up until the 26 SDK then I imagine they might have interest in keeping it working | 18:05:33 |
| emily | would be a lot cleaner than worrying about keeping an SDK around for years | 18:05:48 |
| emily | especially if we get to the point of "new LLVM chokes on the old SDK now" etc. | 18:05:59 |
| emily | (or more plausibly, new Swift chokes on Swift parts of the old SDK) | 18:06:17 |
| Randy Eckenrode | The problem is Foundation reexports Observable. That makes import Foundation immediately fail because it hits macros right away. | 18:06:44 |
| emily | they won't have any way of knowing that it matters for someone to have it work without us letting them know after all | 18:06:47 |
| emily | it surely can't be hard to just skip over macro definitions when bootstrapping right? | 18:07:13 |
| Randy Eckenrode | The parser has no idea without support. It needs swift-syntax, which is written in Swift. | 18:07:52 |
| emily | (I mean, maybe it can be, but the people working on the Swift bootstrap would know better than I :) ) | 18:07:53 |
| Randy Eckenrode | If we hit that point, we can bootstrap from a binary distribution or a know good one. | 18:08:03 |
| Randy Eckenrode | I think it’a one guy working on it: | 18:08:23 |
| Randy Eckenrode | * | 18:08:27 |
| Randy Eckenrode | * | 18:08:42 |
| Randy Eckenrode | * | 18:09:35 |
| emily | if we're planning ahead about things like a binary bootstrap or an old compiler or an old SDK I don't see why we shouldn't spend that effort on taking 5 minutes to open a bug report upstream… | 18:09:48 |
 toonn | Are you sure the macros are not used in any code hit during a compiler compile? | 18:10:13 |
| emily | are we talking about Foundation.framework/Versions/C/Modules/Foundation.swiftmodule/x86_64-apple-macos.swiftinterface? I see e.g.
@available(macOS 12, iOS 15, tvOS 15, watchOS 8, visionOS 1, *)
@freestanding(expression) public macro bundle() -> Foundation.Bundle = #externalMacro(module: "FoundationMacros", type: "BundleMacro")
| 18:11:17 |
