How to ensure backward compatibility of inclusive range?

#1

Hello!

I’m new to rustlang and I have been working on an application which seems to give deprecation warnings for the inclusive range syntax. The recommended syntax is ..= but that causes compilation with rustc 1.24 to fail (since this new syntax was intriduced in 1.26).
What is the correct way to handle such issues?
It would be great if you could tell a generic way of handling any such issues rather than just this one.
Thank you for your time. :slight_smile:

#2

Is there any particular reason you’re using Rust 1.24? Or is it just to ensure backwards compatibility for your library?

3 Likes
#3

Add #![allow(ellipsis_inclusive_range_patterns)] to your crate root.

4 Likes
#4

It is just to ensure the backward compatibility for the application.

#5

Thanks! This works but I was expecting ..= to work with 1.24, turns out, this allows ... in the newer versions and throws https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#unknown-lints in 1.24. Is this how its supposed to be?

#6

Yes. If you want to suppress that, then add #![allow(unknown_lints)].

#7

Thanks a lot. Although, I’m not sure if that is a good thing to do. That would suppress all the warnings about unknown lints and it might be tough to catch spelling mistakes in lints thereafter. :confused:

#8

Shrug. I’m not sure what else you expect here. This is the price one pays for maintaining an old MSRV: the rest of the ecosystem will eventually leave you behind. My suggestion is to just stop maintaining such an old MSRV (even though I do the same for some crates, I tend to only be strict about it for very widely used crates).

Otherwise, if this really bothers you, then you can use #[allow(ellipsis_inclusive_range_patterns, unknown_lints)] at each use of ... directly in order to limit its scope instead of applying it to the entire crate.

2 Likes
#9

Thanks for explaining and the suggestion. :slight_smile:

1 Like