Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
mlir piggybacks onto LLVM_BUILD_LLVM_DYLIB for determining if a
shared libMLIR.so is emitted. This also fixes build failures
in MLIR 20+ where tablegen'd files aren't generated.
In file included from /build/mlir-src-21.0.0-unstable-2025-03-09/mlir/include/mlir/IR/UseDefLists.h:16,
from /build/mlir-src-21.0.0-unstable-2025-03-09/mlir/include/mlir/IR/Value.h:17,
from /build/mlir-src-21.0.0-unstable-2025-03-09/mlir/include/mlir/IR/BlockSupport.h:16,
from /build/mlir-src-21.0.0-unstable-2025-03-09/mlir/include/mlir/IR/OperationSupport.h:18,
from /build/mlir-src-21.0.0-unstable-2025-03-09/mlir/include/mlir/IR/Dialect.h:17,
from /build/mlir-src-21.0.0-unstable-2025-03-09/mlir/tools/mlir-lsp-server/mlir-lsp-server.cpp:9:
/build/mlir-src-21.0.0-unstable-2025-03-09/mlir/include/mlir/IR/Location.h:145:10: fatal error: mlir/IR/BuiltinLocationAttributes.h.inc: No such file or directory
145 | #include "mlir/IR/BuiltinLocationAttributes.h.inc"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
This essentially reverts 7ce8e7c4cf
asl20-llvm does not produce a valid SPDX ID, it produces a valid SPDX
Expression. However, this is not what the spdxId field promises.
This is relevant because we cannot produce valid SBOMs (e.g. CycloneDX)
using this field as the schemas for these SBOMs check that the IDs are
valid.
This change leaves us with consistently valid SPDX IDs at the cost
of slightly less convenience.
