Build failure of esp-rom-sys for esp32

[SolidTux]

Bug description

Project generated with esp-generate fails with the following error

error[E0599]: no method named `to_ascii_lowercase` found for type `i8` in the current scope
  --> /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/esp-rom-sys-0.1.3/src/lib.rs:86:31
   |
86 |             let val = (*s1_i).to_ascii_lowercase() as i32 - (*s2_i).to_ascii_lowercase() as i32;
   |                               ^^^^^^^^^^^^^^^^^^ method not found in `i8`

error[E0599]: no method named `to_ascii_lowercase` found for type `i8` in the current scope
  --> /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/esp-rom-sys-0.1.3/src/lib.rs:86:69
   |
86 |             let val = (*s1_i).to_ascii_lowercase() as i32 - (*s2_i).to_ascii_lowercase() as i32;
   |                                                                     ^^^

To Reproduce

Repository

• install toolchain with espup
• generate esp32 project with esp-generate (options don't seem to matter, I tried different ones)
• run cargo run

Expected behavior

The library compiles

Environment

• Target device: esp32
• Crate name and version: esp-rom-sys 0.1.3

[bugadani]

Can you please paste the output of rustc +esp -vV?

[SolidTux]

rustc 1.90.0-nightly (abf50ae2e 2025-09-16) (1.90.0.0)
binary: rustc
commit-hash: abf50ae2e46066e67e29fe856f9764c23aa9a3ca
commit-date: 2025-09-16
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.1

[SolidTux]

Also, I'm running this inside a devcontainer that's generated with

FROM rust:latest
RUN cargo install espup cargo-binstall --locked
RUN espup install
RUN cargo binstall esp-generate espflash probe-rs-tools
RUN cargo install esp-config --features=tui --locked
RUN sh -c "echo \"source /root/export-esp.sh\" >>/root/.profile"

[SolidTux]

I just tried with rust:1.89 as a base image, which solves the build issue. The esp rustc is still 1.90, so I don't know why that changes anything.

[bugadani]

I'm not sure what's going on exactly, c_char is u8, not i8. That change has been made in February and caused quite some stir. Regardless, one way forward is for us to stop relying on the assumption that c_char == u8.

[bjoernQ]

The compilation error is fixed on main now