Apple added a new CPU subtype with the macOS 27 sdk, which describes
CPUs with extra pointer authentication features. The apple A20 and M6
chips have this subtype, and code in the new macOS 27 sdk needs the
compiler toolchain to be able to handle these architectures, so that it
can be linked against.
While the wrapper's bash script was broken, clang-tidy would have failed
to check a project with an include such as assert.h because it wouldn't
have been able to find that header file.
The wrapper script relies on features only available with bash, namely
arithmetic evaluation as in `while (( $# )); do`. So let's ensure that
the shebang is patched to use bash. (bash's POSIX `sh` evaluates this as
intended.)
A minimal reproducer with a project that generally ought to pass
clang-tidy checking may look like so:
```nix
{
pkgs ? import <nixpkgs> { },
}:
pkgs.fwupd.overrideAttrs (
final: prev: {
nativeBuildInputs = prev.nativeBuildInputs ++ [ pkgs.clang-tools ];
preCheck = ''
ninja clang-tidy
'';
}
)
```
Before, you may see many errors about missing headers and some lines
that suspiciously look like bash errors.
```
fwupd> >>> /nix/store/gf6qdh329rc8lbby710r9rzhwqkkgv3h-clang-tools-21.1.8/bin/clang-tidy --use-color -quiet -p /build/source/build /build/source/plugins/uf2/fu-self-test.c
fwupd> /nix/store/gf6qdh329rc8lbby710r9rzhwqkkgv3h-clang-tools-21.1.8/bin/clang-tidy: line 5: 129: not found
fwupd> /nix/store/gf6qdh329rc8lbby710r9rzhwqkkgv3h-clang-tools-21.1.8/bin/clang-tidy: line 23: 129: not found
fwupd> 276 warnings and 1 error generated.
fwupd> Error while processing /build/source/plugins/uf2/fu-self-test.c.
fwupd> /nix/store/dm7fg33sqnjxkwdpirnnbnx7wyi89m82-glib-2.88.3-dev/include/glib-2.0/glib/gtypes.h:41:10: error: 'time.h' file not found [clang-diagnostic-error]
fwupd> 41 | #include <time.h>
fwupd> | ^~~~~~~~
```
With this change, these clang-tidy errors no longer appear.
ba34cbad41
moved the location of the handling for _lldb.so in the python bindings,
which we delete in gnu-install-dirs.patch. to allow the patch to apply
to lldb 23, we make the patch version dependent and move the deletion to
the new location in the source for the llvm 23 version.
Older versions of LLDB crash on macOS 27 when starting a debugging
session on macOS 27 due to a stack overflow in `ParseExportTries`.
The fixes from LLVM 23 can’t be cherry-picked due to other changes. They
have been manually backported and squashed into a single patch.
The patch failed to apply on 18 and 19. We have to version it.
LLVM 18 has no MLIR_SRC_SHARDER_TABLEGEN_EXE. LLVM 19 and 20 fail to
apply the 21+ patch due to mechanical hunk failures, but otherwise use
an identical patch to 21+.
This test depends on being able to sign a bundle, which sigtool is not
able to do. Once we have a compatible wrapper for rcodesign, which can
sign bundles, it should be possible to enable it again.
