0.15.2
A dependency-requirement release on top of 0.15.1, closing the same deadlock that release opened up β in the one requirement it left behind. No API changes and no rendering or parsing behavior changes.
MachOKitis required as0.52.101 ..< 0.53.0instead ofexact: "0.52.100"β an exact requirement in a library deadlocks any consumer that also depends on MachOKit directly.0.15.1fixed this for MachOObjCSection and left MachOKit exact; RuntimeViewer hit it the moment it moved to0.52.101.- The lower bound moves to
0.52.101, picking up the ObjC header info lookup fix for dyld subcaches. MachOKitExtensionsmoves tofrom: "0.1.1"β bind resolution in legacy binaries that carry no chained fixups, and dyld cache image matches that are ranked rather than first-hit.swift-semantic-stringmoves tofrom: "0.3.0", which is what0.15.1's changelog already claimed whilePackage.swiftstill said0.1.5. The resolved version was0.3.0either way, because MachOObjCSection requires it; only the spelling here was stale.- Three retroactive conformances are spelled
@retroactiveβFileHandleandMemoryMappedFileconforming toMachONamespacing, andObjCClass64/ObjCClass64.LayouttoLocatableLayoutWrapper/LayoutProtocol. Both the types and the protocols live in other modules, so the attribute is what the compiler asks for. Package.swiftno longer reads a.package.envfile. Local-dependency switching is environment variables only.
Rendered output is byte-for-byte unchanged.
Highlights
The requirement 0.15.1 did not convert
0.15.1 made the case at length: two exact: requirements on one package have no intersection unless they name the same version, so a library that pins exactly deadlocks every consumer that also depends on that package directly. It converted MachOObjCSection to a range and left MachOKit as exact: "0.52.100".
RuntimeViewer depends on this package and on MachOKit directly. When it moved to 0.52.101 for the subcache fix, resolution stopped having a solution:
error: Failed to resolve dependencies Dependencies could not be resolved because
'runtimeviewercore' depends on 'machoswiftsection' 0.15.1.
'machoswiftsection' 0.15.1 cannot be used because 'machoswiftsection' 0.15.1
depends on 'machokit' 0.52.100 and 'runtimeviewercore' depends on 'machokit' 0.52.101.
Same failure, same shape, one release later. Bumping the pinned version would only move the deadlock to the next MachOKit patch either side wants first, so the requirement itself becomes a range.
The upper bound stops at the next minor rather than opening to 1.0.0, for the reason 0.15.1 gave for MachOObjCSection: this line has removed public API within a minor before, and a wider bound would let a future release float this package onto an incompatible MachOKit.
What 0.52.101 carries
One three-line fix, upstream p-x9/MachOKit#310: ObjC header info lookup resolved against the wrong subcache when reading a split dyld shared cache. Nothing in this package changes shape because of it.
Compatibility
- No API additions, removals or renames. No snapshot
formatVersionchange. - Consumers that pinned
MachOKitto0.52.100alongside this package can now move anywhere in0.52.101 ..< 0.53.0; that is the point of the release. - Pinned dependencies for this release β the first four lines differ from
0.15.1:MachOKitβ0.52.101 ..< 0.53.0.MachOKitExtensionsβfrom: "0.1.1".swift-semantic-stringβfrom: "0.3.0".MachOObjCSectionβ0.8.104 ..< 0.9.0, unchanged and for the reasons given in0.15.1.swift-demanglingβ0.4.5 ..< 0.5.0, unchanged and for the reasons given in0.14.1.
Requirements
- Swift 6.2+
- Xcode 26.0+ (CI validates the test matrix on Xcode 26.6 / macOS 26)