The vendored January tree did not parse at all on a current nightly: 36 errors in iris-core, all from one syntax change. `impl const Trait for T` is now `const impl Trait for T`, with generics on the `impl`. Bounds are unaffected, and the traits were already declared `const trait` -- so the diagnosis recorded in RUST.md was wrong, and pinning back to a January nightly would only have deferred this. Everything else (the unresolved UiVec2/Vec2/impl_op imports, a Color<u8> resolving to wgpu_types::Color) cascaded from the seven files that failed to parse. The pin is dated rather than `nightly` because that is exactly the failure: a rolling channel moving under a build Dev Updater runs unattended. It carries the components and Android targets too, so a fresh clone provisions itself. Also drops two `#![feature]` gates the compiler reports as declared and unused, since the build stays warning-clean, and takes rustfmt's import order in attr.rs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
12 lines
661 B
TOML
12 lines
661 B
TOML
# iris needs nightly (see the #![feature] list in core/src/lib.rs and src/lib.rs).
|
|
# The pin is dated rather than "nightly" because the const-traits feature set
|
|
# changes shape between nightlies: on 2026-09-04 the vendored January tree would
|
|
# not parse at all, because `impl const Trait for T` had become
|
|
# `const impl Trait for T`. A rolling channel turns that into a build that
|
|
# breaks unattended on whatever machine Dev Updater happens to build on.
|
|
# Advance this deliberately, with the feature list in RUST.md's I0b.
|
|
[toolchain]
|
|
channel = "nightly-2026-09-03"
|
|
components = ["clippy", "rustfmt"]
|
|
targets = ["aarch64-linux-android", "x86_64-linux-android"]
|