| 26 Jun 2026 |
Randy Eckenrode | Oh, right. The test suite. | 11:11:32 |
emily | you disabled that | 11:15:20 |
emily | but the dependency isn't conditional | 11:15:26 |
emily | I believe it's being used for the build system now or something | 11:15:39 |
| 27 Jun 2026 |
| dinckelman joined the room. | 11:57:01 |
Randy Eckenrode | Is GCC 15.3 known broken on Darwin? I’m getting GFortran build failures on my Swift branch. | 12:18:41 |
Myria | GCC 15.3 was reverted because it didn't bring in the new iains patches | 12:19:10 |
Myria | It's got a different pr that will fix it, but that's in the queue | 12:19:40 |
Randy Eckenrode | I must have rebased on staging before the revert. | 12:24:45 |
emily | Randy Eckenrode: thank you again for mentioning the 1Password native autofill support thing | 14:15:14 |
emily | life-changing | 14:15:18 |
emily | I used to fight with that browser extension multiple times every day | 14:15:24 |
emily | it's in the nightlies at least, not sure if it's made its way to stable yet | 14:31:59 |
emily | supports passkeys too | 14:32:02 |
Randy Eckenrode | It’s in the beta channel now. If you’re using the 1Password packages with nix-darwin, switch your channel to the beta one. | 15:02:32 |
Randy Eckenrode | So … we have a problem. Some frameworks use external macro implementations. Those are only shipped with Xcode. They’re not available in the public Swift toolchain nor in the SDK. | 15:08:15 |
emily | what kind of file? | 15:25:52 |
Randy Eckenrode | FoundationModels uses an external macro implementation in a dylib. | 15:32:20 |
Randy Eckenrode | I ran into it when building handy with the updated Swift toolchain. It uses the 26.5 SDK, which has the framework but not the macros dylib. | 15:32:54 |
Randy Eckenrode | I’m overriding the check in handy’s build.rs, but this could be a problem in the future. | 15:33:39 |
Randy Eckenrode | These are the macros shipped with Xcode. The only macros distributed upstream are Swift and Observation. We also have Swift Testing macros that we build from that project.
libAppIntentsMacros.dylib* libFoundationMacros.dylib* libMMIOMacros.dylib* libPreviewsMacros.dylib* libSwiftMacros.dylib*
libFinanceMacros.dylib* libFoundationModelsMacros.dylib* libMMIOMacros.tbd libSwiftDataMacros.dylib* libSwiftUIMacros.dylib*
libFinanceMacros.tbd libFoundationModelsMacros.tbd libObservationMacros.dylib* libSwiftDataMacros.tbd libTipKitMacros.dylib*
| 15:40:01 |
Randy Eckenrode | For example, SwiftUI in Xcode 27 replaced its State property wrapper with a macro. It’s likely we will not be able to build SwiftUI applications with the 27.x SDK. | 15:42:32 |
emily | is there anything that might correspond to their source code in the SDK? | 15:43:49 |
Randy Eckenrode | Not as far as I can tell. | 15:45:04 |
Randy Eckenrode | The only way I can see us being able to build those apps is if we use xcodes to scrape the macros from Xcode, and they happen to actually work with other Swift toolchains. Those macros would obviously have to be marked unfree. | 15:45:14 |
emily | @attached(extension, conformances: FoundationModels.Generable, names: named(init(_:)), named(generatedContent)) @attached(member, names: arbitrary) public macro Generable(description: Swift.String? = nil) = #externalMacro(module: "FoundationModelsMacros", type: "GenerableMacro")
| 15:45:39 |
emily | I don't suppose the relevant symbols are in the dyld cache? 🤔 | 15:45:46 |
Randy Eckenrode | No. The stubs point to Xcode. | 15:45:56 |
Randy Eckenrode | * | 15:46:09 |
Randy Eckenrode | They’re used at compile-time, so I wouldn’t expect them to be in the dyld cache anyway. | 15:46:26 |