search

rust-osdev / uart_16550

Minimal support for uart_16550 serial output.
MIT License
33 stars 24 forks source link

remove unknown nightly feature 'const_ptr_offset' #22

Closed tsatke closed 2 years ago

tsatke commented 2 years ago

This seems to let it build again.

Seems related to https://github.com/rust-lang/rust/issues/71499 and https://github.com/rust-lang/rust/pull/93957

phil-opp commented 2 years ago

Thanks a lot!

phil-opp commented 2 years ago

Published as v0.2.17

phip1611 commented 2 years ago

I am aware of that people break builds with feature updates (0.x.y) from time to time (especially if major is still 0) but breaking builds in bugfix updates is a bit.. unexpected. This broke my builds :)

josephlr commented 2 years ago

This change was a necessary bugfix to allow this crate to continue building on the latest nightly. Without this change, the crate would no longer compile.

Im confused how this actually broke you though. This change should be fine on older rustc versions. What specific compiler error are you getting? What version of rustc are you using? Are you using version 0.2.18 of this crate?

phip1611 commented 2 years ago

This change was a necessary bugfix to allow this crate to continue building on the latest nightly. Without this change, the crate would no longer compile.

Ah okay, I see. Well, this is my project respectively the fix: https://github.com/phip1611/diplomarbeit-impl/commit/7296fbc58ff28650d1a51cfcc533733c18b59fd4 It's on 1.61 nightly. I could fix this by pinning version 0.2.16.

phil-opp commented 2 years ago

Changed feature gates are the main difficulty of maintaining crates that target nightly Rust. Often, there is no way to keep supporting older nightly versions in such cases. In this case, the older nightlies expect the feature gate, but the newer ones throw an error because the feature gate no longer exists (since the feature was stabilized).

We had a lot of similar cases for the x86_64 crate and decided to resolve it by supporting only the latest nightly. Under this policy, we don't consider updating/removing feature gates as breaking changes because it effectively fixes a compile error.

The main reason for doing only patch releases as opposed to changing the minor version are transitive dependencies. For example, if we did a minor version bump for each feature gate update in x86_64, all dependent (library) crates would require a new release as well since cargo update only updates the patch version for v0.x.y crates. Coordinating this across different crates maintained by different people was a lot of effort and led to much more breakage. Because of this, we decided to consider such updates as bugfixes from then on and that policy worked much better.

That being said, it might be possible to continue supporting older nightlies through cfg attributes depending on the nightly version. However, I'm not sure if this is worth the effort. It would only work in certain cases and we don't want to increase the maintenance burden too much. Moving the crates to stable Rust as soon as possible seems like the better solution.

phip1611 commented 2 years ago

Yeah, I agree. The longer I think about it, the more your approach makes sense. That's what people have to expect when working on nightly Rust.

through cfg attributes depending on the nightly

Probably overkill, as long as the lib doesn't have 100k active users :D