Skip to content

Commit

Permalink
Add rust-version field to Cargo.toml
Browse files Browse the repository at this point in the history
  • Loading branch information
tuffy committed Jun 14, 2024
1 parent 8695428 commit 241eaed
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,14 @@
name = "bitstream-io"
description = "Library for reading/writing un-aligned values from/to streams in big-endian and little-endian formats."
keywords = ["bitstream", "endian", "big-endian", "little-endian", "binary"]
version = "2.4.0"
version = "2.4.1"
authors = ["Brian Langenberger <bjl@usa.net>"]
license = "MIT/Apache-2.0"
documentation = "https://docs.rs/bitstream-io/"
homepage = "https://github.com/tuffy/bitstream-io"
repository = "https://github.com/tuffy/bitstream-io"
edition = "2018"
rust-version = "1.79"

[dependencies]
core2 = {version = "0.4", optional = true, default-features = false, features = ["alloc"]}
Expand Down

4 comments on commit 241eaed

@francisdb
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for this change? Libs depending on this package will require the latest rust version and fail as it takes a while for that version to end up on default build nodes.
https://github.com/francisdb/vpin/actions/runs/9534568985/job/26280157347

Adding github actions builds to this project would indicate this issue.

@tuffy
Copy link
Owner Author

@tuffy tuffy commented on 241eaed Jun 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason for this change is that the latest version of Rust allows for building read/write method variants which can catch overreads/overwrites much sooner than before. For example, this will compile:

let x: u32 = r.read(64)?;

but it always fails at runtime even though the number of bits being read is always the same.

However, using a new read method variant which takes a constant number of bits:

let y: u32 = r.read_in::<64, _>()?;

this is an error that will be caught at compile-time using assertions in the new const blocks which just stabilized.

And catching possible errors at compile-time rather than at run-time seems rather helpful in the long run.

@francisdb
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Makes sense. I guess the issue is then that this is not a major version change or one of the libs I use having too loose dependency versions to bitstream-io. Anyway, should fix itself once GitHub catches up.

@sdroege
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requiring a newer Rust version is not a breaking change, so this is all working as intended. The main problem is that cargo does not implement Rust-version-dependent dependency resolution yet, see rust-lang/cargo#13873 etc.

This means that currently cargo will (for now by default) happily pull in newer versions of dependencies even if an older Rust version is used.

Please sign in to comment.