Replace the "no-std" feature with a "std" feature

[egrimley-arm]

Negative feature names are rejected by Clippy: they cause confusion when several crates depend on the same crate but with different sets of features.

The default set of features is changed but anyone who specifies --no-default-features or default-features = false will need to change what features they specify, so this is an incompatible change.

Also update toolchain from 1.58.1 to 1.60.0 in .github/workflows/ci.yml as regex-syntax v0.7.2 requires rustc 1.60.0 or newer.

[ionut-arm]

Nice, thank you!

You might want to sync with @ithinuel (see #113 ) regarding proper "no-std" support :)

[ithinuel]

I'm happy to remove the last commit from my PR if this one is merged first.

[egrimley-arm]

Summary: I have proposed three ways of getting the CI tests to pass:

• Update toolchain: egrimley-arm@5811849
• Add restrictions to Cargo.toml files: egrimley-arm@b6194e3
• Add Cargo.lock to repo: egrimley-arm@23a8864

The first way seems bad because we want to keep things working with the old toolchain. I quite like the third one because it doesn't unnecessarily affect users of the crate with a recent toolchain, but perhaps it increases the maintenance burden.

Which shall we use? Or is there a fourth way?

[gowthamsk-arm]

Thanks for the patch @egrimley-arm. :)
Usually for library crates the cargo.lock file gets ignored when the crate is added as a dependency to any binary crate and the lock file in the binary crate might still cause the issue when compiled against 1.58.1. So I'm inclined towards the Cargo.toml commit.

@ionut-arm what do you think?

[ithinuel]

If building with older toolchain is a requirement, it should be committed to with the definition of an MSRV (not present on any of the 3 listed commits). This would need to go with the restriction imposed on log and regex-syntax.

This restriction could be mitigated by (optionally) depending on multiple version of log and regex-syntax and using features to enable compatibility with older/newer versions of the toolchain.
Choice will depend on what the default should be:

• building on 1.58.1
• or building on 1.60.0+

(see https://slint.dev/blog/rust-adding-default-cargo-feature)

Keeping Cargo.lock for CI purposes will make CI have a different experience than new users and hide new breakage introduced by dependencies.

I'd also highly recommend to use stable rather than a specific version in CI.
If an MSRV is defined, then both the MSRV and stable should be run.

[egrimley-arm]

I'd also highly recommend to use stable rather than a specific version in CI. If an MSRV is defined, then both the MSRV and stable should be run.

That sounds like a good idea. I've just made a separate PR for that: #116.

[ionut-arm]

I'm against the Cargo.lock approach for the same reasons that @gowthamsk-arm and @ithinuel highlighted.

@gowthamsk-arm - was there a strong reason to keep the MSRV at 1.58?

[egrimley-arm]

I have reverted this PR back to the second version, the one that modifies */Cargo.toml.

[gowthamsk-arm]

One of the distributions that Parsec is packaged for has 1.58 as the minimum RUST version so we had to set it as MSRV.

[ithinuel]

Since this PR sets the dependencies' version range, should'nt it also include:

• the setting of the MSRV
• the setup of github flow for the msrv & stable?

i.e. what's in #116

[egrimley-arm]

Since this PR sets the dependencies' version range, should'nt it also include:

• the setting of the MSRV
• the setup of github flow for the msrv & stable?

i.e. what's in #116

As I see it, this PR is mostly about replacing no-std with std, with minimal additions to get CI to pass. Presumably if #116 goes in soon it doesn't really matter how the commits are divided between PRs.