| 1 Dec 2025 |
 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 |
| Randy Eckenrode | Because I’m going probably going to have to reproduce with the recommended build scripts and toolchains, which will require more than five minutes. Also, five minutes spent on that is time not spent on other things. | 18:11:21 |
| emily | which seems like it would be really easy to parse and just map to a stub error | 18:11:30 |
