Minimum supported Rust version v.s. SemVer

[rjloura]

When running clippy on rust 1.35 I encounter the following error:

error[E0658]: use of unstable library feature 'alloc': this library is unlikely to be stabilized in its current form or name (see issue #27783)
  --> /home/rui/.cargo/registry/src/github.com-1ecc6299db9ec823/smallvec-1.0.0/lib.rs:38:1
   |
38 | extern crate alloc;
   | ^^^^^^^^^^^^^^^^^^^

For my project the url crate is pulled in by gotham, but this occurs when I run clippy on rust-url by itself. The tree is:

$ cargo tree
url v2.1.0 (/home/rui/git/rust-url)
├── idna v0.2.0 (/home/rui/git/rust-url/idna)
│   ├── matches v0.1.8
│   ├── unicode-bidi v0.3.4
│   │   └── matches v0.1.8 (*)
│   └── unicode-normalization v0.1.11
│       └── smallvec v1.0.0 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
├── matches v0.1.8 (*)
└── percent-encoding v2.1.0 (/home/rui/git/rust-url/percent_encoding)
SNIP!

What I don't understand is how this tree was built. idna is currently at version 0.2.0 and it specifies unicode-normalization version of 0.1.5 (https://github.com/servo/rust-url/blob/master/idna/Cargo.toml).

The only thing I did notice was that unicode-normalization was bumped to it's new version 3 days ago and that brought in the smallvec v1.0.0 dependency. (https://github.com/unicode-rs/unicode-normalization/blame/master/Cargo.toml)

For this project I need to stay on rust 1.35. I am not sure why the dependency tree changed without the rust-url version changing.

[SimonSapin]

It looks like unicode-rs/unicode-normalization#46 increased our minimum Rust version from under us. The last PR that we merged succeeded with 1.33:

rust-url/.travis.yml

Line 6 in 7d2c9d6

- rust: 1.33.0

[SimonSapin]

For this project I need to stay on rust 1.35.

You may be able to do this by adding a dependency from your crate unicode-normalization, with a requirement for some older version number.

[rjloura]

For this project I need to stay on rust 1.35.

You may be able to do this by adding a dependency from your crate unicode-normalization, with a requirement for some older version number.

@SimonSapin thank you for taking a look at this. Unfortunately, including unicode-normalization = "0.1.5" doesn't fix the issue.

Can you help me understand how this is happening? If the versions of rust-url and idna haven't changed, and idna @ v0.2.0 includes a dependency on unicode-normalization with a version of 0.1.5 (https://github.com/servo/rust-url/blob/master/idna/Cargo.toml#L3), why is rust-url > idna bringing in unicode-normalization 0.1.11.

It is also worth noting that unicode-normalization @ v0.1.5 has NO dependency on smallvec at all. The smallvec dependency came in at unicode-normalization @ v0.1.7. The issue is actually with smallvec v1.0.0 which shouldn't be brought in at all under idna v0.2.0 > unicode-normalization 0.1.5

[SimonSapin]

unicode-normalization = "0.1.5" in the [dependencies] section of Cargo.toml means any version from 0.1.5 but less than 0.2.0: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html

Try unicode-normalization = "= 0.1.5"

[rjloura]

Try unicode-normalization = "= 0.1.5"

Ah thank you @SimonSapin! That worked. Sorry for the noise.

[SimonSapin]

I didn’t realize that this would also affect our CI since we’re testing on 1.33 which was the minimum supported version before this unicode_normalization change. Right now any PR fails: #571 (comment)

The maintainers of that crate have decided that they do not consider increasing the minimum supported Rust version to be a breaking change that requires a corresponding SemVer version number: unicode-rs/unicode-normalization#50

For this repository we never formalized a policy, although url 1.x was still tested with Rust 1.17 when we released url 2.0.0.

So as far as I can tell we’ll have to pick one of:

• Restrict our dependency (in idna) on unicode_normalization to something like >= 0.1.5, <= 0.1.9
• Or adopt the same policy of accepting MSRV increase and not versioning them a as breaking change

@nox, what do you think?

[nox]

I think it's pretty bad for unicode-normalization to not care about MSRV, but this is not a hill I'm willing to die on. Restricting dependencies with ranges cause more issues than fix them in the long run, so I'm not in favour of that. I guess we can just document that this crate doesn't care about MSRV. :(

[SimonSapin]

Well I wouldn’t phrase it as “not care”, but yeah that might be easiest.

[o0Ignition0o]

In order to reply to this comment
I have just bumped the minimum supported rustc version (in the pull request branch), which to me is a breaking change IMO (hence me saying i can probably rollback the minimum rustc version support, and pin unicode-normalization instead).

I feel a bit stuck because I can either keep an outdated and possibly unsound (yet rustc 1.33 compatible) dependency by pinning unicode-normalization version 0.1.9, or bump the minimum supported rustc version to 1.36, which probably requires to bump rust-url as well in order to respect semver.

This issue adds even more weight as to why we might want to pin unicode-normalization (0.1.5 if i get the thread correctly ?)

[rjloura]

For my use case it would be more beneficial to have rust-url pin the unicode-normalization version.

If I understand the other alternative (not considering raising MSRV to be a breaking change) correctly, anyone attempting to use rust-url with rust 1.35 (or lower) would have to pin rust-url and (probably) its dependencies explicitly. The decision by by unicode-normalization to not regard MSRV as a breaking change seems to have a cascade effect, and from my view it would be good to stop that cascade as close to the source as possible.

Just my 2 cents as a random user of these crates.