Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Swift: macro plugin host fails with "Bad CPU type in executable" when tracing an Xcode 27 build on Apple Silicon

Abierto
  • ¿Algo no está bien?
#22,742 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
macos, swift
Área
build-system, devtools

Línea de trabajo

Start with tools/osx64/preload_tracer and reproduce the failure using the provided codeql database create command on the SwiftData project. Compare how traced swift-frontend launches swift-plugin-server, using the reported arm64-only binaries and relocator output as evidence. Done means the traced Xcode build succeeds and creates the CodeQL database without the Bad CPU type error.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Description

Creating a Swift database for an iOS app that uses SwiftData macros (@Model, #Predicate) fails on an Apple Silicon Mac with Xcode 27. swift-frontend runs under the tracer, but it cannot launch the macro plugin host, so every macro expansion fails and the build stops.

Environment

  • CodeQL CLI 2.27.1 (Homebrew cask codeql); the tracer runs from tools/osx64/preload_tracer
  • macOS 27.0.1 on Apple M1 Pro
  • Rosetta 2 installed
  • Xcode 27.0 (27A266a), iOS 27 SDK
  • lipo -archs reports arm64 only for both of these:
    • /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/swift-plugin-server
    • /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend

Steps to reproduce

  1. Use an iOS project containing any SwiftData @Model class.
  2. Put the build in a script, build.sh: 
    #!/bin/bash
set -euo pipefail
xcodebuild -project App.xcodeproj -scheme App -destination 'generic/platform=iOS Simulator' -derivedDataPath /tmp/dd-codeql CODE_SIGNING_ALLOWED=NO clean build
  3. Run: 
    codeql database create /tmp/db --language=swift --overwrite --command=./build.sh

Expected behaviour

The database is created. Running ./build.sh without CodeQL ends in ** BUILD SUCCEEDED **.

Actual behaviour

The build fails with exit code 65. Every file using a SwiftData macro reports:

error: external macro implementation type 'SwiftDataMacros.PersistentModelMacro' could not be found for macro 'Model()'; compiler plugin '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/swift-plugin-server' could not be loaded: Bad CPU type in executable

Related observations

  1. Without the macro plugin, the tracer copes with the arm64-only toolchain. A probe with --command="xcodebuild -version" runs xcodebuild and prints Xcode 27.0 / Build version 27A266a, and the plain build of the same project (without CodeQL) succeeds. So the failure seems specific to how the traced swift-frontend launches swift-plugin-server.
  2. During the traced build, the relocator makes patched .slice.arm64 copies of xcodebuild, SWBBuildService, actool, ibtoold and ld. Each one logs an install_name_tool header-padding error and then falls back to a short symlink, after which tracing continues normally. I include this in case it's related: 
    error: .../install_name_tool: changing install names or rpaths can't be redone for: .../xcodebuild.semmle.<id>.slice.arm64 (for architecture arm64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
relocator: resorting to replacing "/Applications/Xcode.app/Contents/Developer/usr/bin" with short symlink "/tmp/<random>"
Lenguaje dominante
CodeQL
Estrellas
10.2k
Forks
2.1k
Merge medio
2 d 11 h
PR fusionados (30 d)
155

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/codeql

Todos los issues de github/codeql

Issues similares

Más issues de Build System

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.