Compilation fails in embedded-io

[vortex314]

UPDATE: Read this

Following the build instruction it fails with

   Compiling atomic-waker v1.0.0
   Compiling strum v0.23.0
   Compiling embedded-io v0.3.1
error[E0658]: generic associated types are unstable
  --> /home/lieven/.cargo/registry/src/github.com-1ecc6299db9ec823/embedded-io-0.3.1/src/asynch.rs:17:5
   |
17 | /     type ReadFuture<'a>: Future<Output = Result<usize, Self::Error>>
18 | |     where
19 | |         Self: 'a;
   | |_________________^
   |
   = note: see issue #44265 <https://github.com/rust-lang/rust/issues/44265> for more information
   = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable

error[E0658]: where clauses on associated types are unstable
  --> /home/lieven/.cargo/registry/src/github.com-1ecc6299db9ec823/embedded-io-0.3.1/src/asynch.rs:17:5
   |
17 | /     type ReadFuture<'a>: Future<Output = Result<usize, Self::Error>>
18 | |     where
19 | |         Self: 'a;
   | |_________________^
   |
   = note: see issue #44265 <https://github.com/rust-lang/rust/issues/44265> for more information
   = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable

error[E0658]: generic associated types are unstable
....

Previous commands :

  git clone https://github.com/esp-rs/rust-build.git
   cd rust-build
   ./install-rust-toolchain.sh
   . export-esp.sh
 cd ../rust-esp32-std-demo/
rustup default esp
cargo build

[elotom]

I have the same issue. For a temporary workaround in Cargo.toml I added:

[patch.crates-io]
embedded-io = { git = "https://github.com/embassy-rs/embedded-io.git", tag = "v0.3.0"}

and then cargo update

[mangelajo]

I am hitting the same issue:

error[E0658]: generic associated types are unstable
  --> /Users/ajo/.cargo/registry/src/github.com-1ecc6299db9ec823/embedded-io-0.3.1/src/asynch.rs:17:5
   |
17 | /     type ReadFuture<'a>: Future<Output = Result<usize, Self::Error>>
18 | |     where
19 | |         Self: 'a;
   | |_________________^

Thanks for the workaround @elotom

[vortex314]

@elotom ,thanks ! That solved the compiling issue. Looks like the author of embedded-io made some braking changes in v0.3.1 requiring another version of the nightly build. Maybe embedded-svc should depend on v0.3.0 and not generic v0.3 As seen in the tree view

├── esp-idf-hal v0.38.1
│   ├── embedded-hal v0.2.7 (*)
│   ├── embedded-hal v1.0.0-alpha.8
│   │   └── nb v1.0.0
│   ├── embedded-svc v0.22.1
│   │   ├── anyhow v1.0.66 (*)
│   │   ├── embedded-io v0.3.1 (https://github.com/embassy-rs/embedded-io#68d52362)
│   │   ├── enumset v1.0.12 (*)
│   │   ├── futures v0.3.25 (*)

[vortex314]

Meetin the next challenge

   Compiling async-channel v1.7.1
   Compiling async-lock v2.6.0
   Compiling async-executor v1.4.1
error: failed to run custom build command for `esp-idf-sys v0.31.10`

Caused by:
  process didn't exit successfully: `/home/lieven/workspace/rust-esp32-std-demo/target/debug/build/esp-idf-sys-885edc63015c1314/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
  cargo:rerun-if-env-changed=MCU
  cargo:rerun-if-env-changed=ESP_IDF_SYS_ROOT_CRATE
  cargo:rerun-if-env-changed=ESP_IDF_VERSION
  cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
  cargo:rerun-if-env-changed=ESP_IDF_CMAKE_GENERATOR
  cargo:rerun-if-env-changed=IDF_PATH
  cargo:rerun-if-env-changed=ESP_IDF_COMPONENTS

  --- stderr
  Build configuration: BuildConfig {
      esp_idf_tools_install_dir: None,
      esp_idf_sdkconfig: None,
      esp_idf_sdkconfig_defaults: Some(
          [
              "sdkconfig.defaults",
              "sdkconfig.defaults.esp32",
              "sdkconfig.defaults.esp32s2",
          ],
      ),
      mcu: None,
      native: NativeConfig {
          esp_idf_version: Some(
              Tag(
                  "v5.0",
              ),
          ),
          esp_idf_repository: None,
          esp_idf_cmake_generator: None,
          idf_path: Some(
              "",
          ),
          extra_components: [],
          esp_idf_components: None,
      },
      esp_idf_sys_root_crate: None,
  }
  Error: '' is not a git respository

  Caused by:
      0: command '"git" "rev-parse" "--show-toplevel"' failed to start
      1: No such file or directory (os error 2)
warning: build failed, waiting for other jobs to finish...

[ivmarkov]

The issue should be fixed now. There were also issues in embedded-svc, but they are also fixed in the meantime (since embedded-svc V0.22.3).

TL;DR: 1) For folks that create projects from scratch or use the esp-idf-template: please put this line in your Cargo.toml to make sure that the issue is workarounded

2) The above would only be necessary for folks using the Espressif Rust toolchain, and only for the next 2 weeks or so. (Not affecting people using latest stock nightly with esp32c3.) That is, until the new version of the toolchain is released, which will be based on Rust 1.65 and then this problem will disappear.

Long story:

• The changes to embedded-io V0.3.1 were actually done by me, with the conscious realization that it will bring these inconveniences to the community (sorry!)
• We were basically caught between a rock and a hard place:
  • embedded-io 0.3.0 stopped working with recent nightlies of Rust due to bugfixes in TAIT
  • embedded-io 0.3.1 fixed these breakages, but removed the GAT feature enablement - as GATs are stabilized in 1.65 anyway - and to be released in ~ 2 weeks - which made it stop working on nightlies older than 1.65 on which the current Espressif toolchain is based on
  • The patched embedded-io I've put in this project basicaly re-enables enablement of the GAT nightly feature, at the expense of a compiler warning on 1.65, which we wanted to avoid in the "official" embedded-io 0.3.1 release

[vortex314]

@ivmarkov thanks for the feedback and the elaborate background information. Looks like Rust is a fast moving target. Hopefully Xtensa chips become part of the official targets of rust, so at least one challenge is gone. Your corrections solve this specific issue, so let's consider this issue closed. I still encounter some issue to find the right esp-idf version, but I'll create other issues for that.

[ivmarkov]

@ivmarkov thanks for the feedback and the elaborate background information. Looks like Rust is a fast moving target. Hopefully Xtensa chips become part of the official targets of rust, so at least one challenge is gone. Your corrections solve this specific issue, so let's consider this issue closed. I still encounter some issue to find the right esp-idf version, but I'll create other issues for that.

Even if Xtensa chips do not become part of the official targets for rust soon, just stabilizing TAITs (and I think the Rust compiler folks are actively working on that) would help tremendously, as we'll stop depending on nightly features, as that's the one single nightly feature we still need. And only for async stuff.

With that said, my understanding is, merging the xtensa stuff into LLVLM (that's the real issue, not rust) is actively being worked on.