`core` fails to build for 16-bit pointer targets after #162879

[joseluis]

core fails to compile for AVR (target_pointer_width = "16") starting with nightly-2026-09-20.

Regression range:

• nightly-2026-09-19: works
• nightly-2026-09-20: fails

I am building for avr-none / ATmega328P with -Zbuild-std=core.

The failure is:

error[E0432]: unresolved imports `crate::num::imp::bignum::Big`, `crate::num::imp::bignum::Digit`
  --> library/core/src/num/imp/flt2dec/strategy/dragon.rs:12:31
   |
12 | use crate::num::imp::bignum::{Big, Digit};
   |                               ^^^  ^^^^^ no `Digit` in `num::imp::bignum`
   |                               |
   |                               no `Big` in `num::imp::bignum`

followed by errors such as:

error[E0425]: cannot find value `POW5TO16` in this scope

This appears to have been introduced by #162879.

That PR changed dragon.rs from using the 32-bit implementation directly:

use crate::num::imp::bignum::{Big32x40 as Big, Digit32 as Digit};

to using aliases selected by pointer width:

use crate::num::imp::bignum::{Big, Digit};

but those aliases, the bignum implementations, and the POW5TO* tables are only defined for:

#[cfg(target_pointer_width = "32")]
#[cfg(target_pointer_width = "64")]

so nothing is selected for target_pointer_width = "16".

Before #162879, AVR successfully used the Big32x40 implementation, so using that path for 16-bit pointer targets may be enough to fix it.

[joseluis]

A minimal reproducer:

cargo new --lib avr-core-regression
cd avr-core-regression

printf '#![no_std]\n' > src/lib.rs

rustup toolchain install nightly-2026-09-19 --profile minimal --component rust-src
rustup toolchain install nightly-2026-09-20 --profile minimal --component rust-src

RUSTFLAGS="-C target-cpu=atmega328p" cargo +nightly-2026-09-19 build -Zbuild-std=core --target avr-none
RUSTFLAGS="-C target-cpu=atmega328p" cargo +nightly-2026-09-20 build -Zbuild-std=core --target avr-none

The first build succeeds; the second fails while compiling core.

[amari-ca]

I submitted a pull request for this just before seeing the issue! #163197