Closed vortex314 closed 1 year ago
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
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
@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 (*)
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...
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:
embedded-io
V0.3.1 were actually done by me, with the conscious realization that it will bring these inconveniences to the community (sorry!)embedded-io
0.3.0 stopped working with recent nightlies of Rust due to bugfixes in TAITembedded-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 onembedded-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@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 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.
UPDATE: Read this
Following the build instruction it fails with
Previous commands :