Skrev en parser som leser den faktiske C‑headeren på 7 308 linjer og verifiserer hvert kallsted, hver enum‑konstant og at hver klasse som eier en peker, er final, etter at en håndskrevet plassholder‑header lot kall til tre fjernede funksjoner kompilere, lenke og krasje.

Situasjon. Tidlig i prosjektet ble C‑grensesnittet representert av en håndskrevet headerfil som beskrev funksjonene appen forventet. Headerfilen kompilerte, appen ble lenket, og kall til tre funksjoner som ikke lenger fantes i kjernen, kom helt frem til å bli utført og krasjet. Både kompilatoren og lenkeren hadde latt seg tilfredsstille av en beskrivelse av biblioteket i stedet for biblioteket selv, og gapet viste seg først under kjøring.

Oppgave. Den ekte headerfilen — 7 308 linjer og 268 deklarasjoner — måtte bli autoriteten, og hver bruk av den i Swift‑koden måtte verifiseres mot den automatisk i stedet for ved gjennomgang.

Handling. Sjekken er en parser som leser den faktiske headerfilen fra oppstrøm og bygger mengden av funksjoner, enum‑konstanter og typer den deklarerer, og deretter leser Swift‑kildekoden og slår opp hvert kallsted og hver konstantreferanse mot den mengden. Et kall til en funksjon som headerfilen ikke deklarerer, får byggingen til å feile. En referanse til en enum‑konstant som har fått nytt navn, får byggingen til å feile. Per i dag refereres det til 132 av de 268 deklarasjonene, og det er nyttig i seg selv å vite hvilke 136 som er ubrukt, fordi det sier nøyaktig hvor mye av kjernen klienten ikke har nådd. Parseren håndhever også en regel kompilatoren ikke kan håndheve: hver Swift‑klasse som eier en peker inn i kjernen, må være final. En klasse som eier en peker og ikke er final, kan få subklasser, og en subklasse som overstyrer deinitialiseringen eller legger til sin egen levetid, endrer når pekeren frigjøres — en use‑after‑free uten noe unsafe‑nøkkelord i nærheten. Regelen sjekkes etter navn over hele treet.

Resultat. Den feiltypen som ga den opprinnelige krasjen, kan ikke komme tilbake, fordi en utdatert referanse nå er en byggefeil og ikke en kjøretidsfeil. Begrensningen er at parseren forstår headerfilens deklarasjoner og ikke semantikken: den beviser at det finnes en funksjon med et navn som stemmer, og en funksjon der betydningen eller eierskapsregelen er endret oppstrøms mens signaturen er beholdt, slipper gjennom uten kommentar.