Conversation
taiki-e
commented
Feb 15, 2026
taiki-e
commented
``` error: package `syn v2.0.115` cannot be built because it requires rustc 1.71 or newer, while the currently active rustc version is 1.68.2 ```
rustbot
added
the
S-waiting-on-review
```
error: this `map_or` can be simplified
--> futures-util/src/stream/stream/flatten_unordered.rs:374:9
|
374 | self.limit.map_or(false, |limit| self.inner_streams.len() >= limit.get())
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.93.0/index.html#unnecessary_map_or
= note: `-D clippy::unnecessary-map-or` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::unnecessary_map_or)]`
help: use is_some_and instead
|
374 - self.limit.map_or(false, |limit| self.inner_streams.len() >= limit.get())
374 + self.limit.is_some_and(|limit| self.inner_streams.len() >= limit.get())
|
```
taiki-e
removed
the
S-waiting-on-review
|
As a user of the futures crate, I was negatively affected by this change, and, at a first glance, this change doesn't make sense, given the syn motivation:
In other words, my understanding is that it is an intentional feature that a library MSRV can be lower (more relaxed), than MSRV of its transitive dependencies. This allows the ultimate consumer to craft a lock file that uses new direct dependencies and older transitive dependencies. Of course, if the motivation here is not to just do what syn does, but rather to directly take advantage of newer language features directly in futures code, then that's totally fine and I'll adjust my code! |
This reverts commit e37b4ed. rust-lang/futures-rs#2989 #3515 (comment)
I'm happy to accept a PR to make MSRV more granular. As we did in crossbeam, this should be easy by using cargo-hack --rust-version in the MSRV check in CI.
This is an approach I prefer not to take, as I've mentioned several times in the past (e.g., smol-rs/async-io#93 (comment)).
Um, your recommendation is to pin dependencies to older versions in MSRV (per smol-rs/async-io#93 (comment)), right? Despite that, is your project still breaking due to dependency's MSRV bump? |
Ah, right, apologies! FWIW, it looks like since then Cargo error messages improved sufficiently to ameliorate "user confusion" concerns. The full error message I get is: Even if dependency is transitive, the error remains actionable (from last week's syn fallout): It points both the specific transitive package that is problematic, as well as the I wonder if today, for CI MSRV testing, one can even avoid generating Cargo.lock.min and instead use newer cargo with MSRV-aware resolver to run
Right, TigerBeetle's context is very peculiar, because we intentionally don't ship any lock files anywhere, as a forcing function to avoid dependencies. More than happy to work-around this on our end! It just seemed to me on the first glance, wrongly, that this change isn't well motivated (I did overlook the fact that futures-rs CI needs to grow more complicated to keep MSRV at 1.68, given that 1.68 doesn't yet have MSRV-aware resolver). |
3 participants
