Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: move ectool to stable Rust #273

Closed
2 tasks
anthonyjmartinez opened this issue Mar 9, 2022 · 4 comments
Closed
2 tasks

feature request: move ectool to stable Rust #273

anthonyjmartinez opened this issue Mar 9, 2022 · 4 comments

Comments

@anthonyjmartinez
Copy link

It appears at this moment that the nightly requirement is due to the dependency on redox_hwio where there appear to be two nightly features in use:

  • asm!, stabilized in Rust 1.59.0 (and I believe referenced here)
  • const_fn_trait_bound, which appears to be tracking stabilization for Rust 1.61.0 (ref)

If the above is correct is it possible to trend towards use of stable Rust? Thanks!

@crawfxrd
Copy link
Member

crawfxrd commented Mar 9, 2022

First one is partially done by redox-os/hwio#4, but I haven't done the using-it-with-stable part. I'll look into it tomorrow.

@anthonyjmartinez
Copy link
Author

Thanks, the referenced here link in that item is to that very MR.

I assume to try the assembly macro from stable it would be necessary to switch to a nightly branch after 1.59.0 was released, and then use the feature from std::arch::asm?

@crawfxrd
Copy link
Member

crawfxrd commented Mar 9, 2022

redox_hwio has a stable feature gate, so I need to update all the points where asm is used.

But is there any reason you want the redox_hwio feature for ectool on stable? It's only used by firmware-update, which won't be on stable either.

You can build on stable right now with:

cargo +stable build --release --manifest-path tool/Cargo.toml

@anthonyjmartinez
Copy link
Author

In general I'd prefer all production Rust be stable, but I don't have a specific rhyme or reason for this beyond a hesitance to depend on that which might never stabilize.

I think I can do what I need to do from the basis of prior art and stable Rust without needing the entire ectool, so I will approach it that way. This can probably be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants