`fst` fails to build with `csv` v1.2.0+

[ZhongRuoyu]

Hi! While packaging Rust 1.68.0 for Homebrew at https://github.com/Homebrew/homebrew-core/pull/125208, we noticed the following build error (full logs here, error starts here):

     Compiling fst-bin v0.4.2 (/private/tmp/fst-20230310-45238-u11ibr/fst-fst-bin-0.4.2/fst-bin)
  error[E0599]: the method `next` exists for mutable reference `&mut DeserializeRecordsIntoIter<Box<(dyn Read + Send + Sync + 'static)>, (BString, u64)>`, but its trait bounds were not satisfied
      --> fst-bin/src/util.rs:154:19
       |
  154  |         match rdr.next() {
       |                   ^^^^ method cannot be called due to unsatisfied trait bounds
       |
      ::: /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/github.com-1ecc6299db9ec823/csv-1.2.1/src/reader.rs:1906:1
       |
  1906 | pub struct DeserializeRecordsIntoIter<R, D> {
       | ------------------------------------------- doesn't satisfy `_: Iterator`
       |
       = note: the following trait bounds were not satisfied:
               `(BString, u64): DeserializeOwned`
               which is required by `DeserializeRecordsIntoIter<Box<(dyn std::io::Read + Send + Sync + 'static)>, (BString, u64)>: Iterator`
               `DeserializeRecordsIntoIter<Box<(dyn std::io::Read + Send + Sync + 'static)>, (BString, u64)>: Iterator`
               which is required by `&mut DeserializeRecordsIntoIter<Box<(dyn std::io::Read + Send + Sync + 'static)>, (BString, u64)>: Iterator`

  error[E0277]: the trait bound `BString: _serde::Deserialize<'_>` is not satisfied
      --> fst-bin/src/util.rs:178:48
       |
  178  |                         self.cur = Some(csvrdr.into_deserialize());
       |                                                ^^^^^^^^^^^^^^^^ the trait `_serde::Deserialize<'_>` is not implemented for `BString`
       |
       = help: the following other types implement trait `_serde::Deserialize<'de>`:
                 &'a Path
                 &'a [u8]
                 &'a str
                 ()
                 (T0, T1)
                 (T0, T1, T2)
                 (T0, T1, T2, T3)
                 (T0, T1, T2, T3, T4)
               and 124 others
       = note: required for `(BString, u64)` to implement `for<'de> _serde::Deserialize<'de>`
       = note: required for `(BString, u64)` to implement `DeserializeOwned`
  note: required by a bound in `csv::Reader::<R>::into_deserialize`
      --> /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/github.com-1ecc6299db9ec823/csv-1.2.1/src/reader.rs:1110:12
       |
  1110 |         D: DeserializeOwned,
       |            ^^^^^^^^^^^^^^^^ required by this bound in `Reader::<R>::into_deserialize`

  Some errors have detailed explanations: E0277, E0599.
  For more information about an error, try `rustc --explain E0277`.
  error: could not compile `fst-bin` due to 2 previous errors
  error: failed to compile `fst-bin v0.4.2 (/private/tmp/fst-20230310-45238-u11ibr/fst-fst-bin-0.4.2/fst-bin)`, intermediate artifacts can be found at `/private/tmp/fst-20230310-45238-u11ibr/fst-fst-bin-0.4.2/target`

This happened to fst-bin version v0.4.2 on all macOS archs/versions, and on Linux (Ubuntu 22.04, x86_64). Some investigation revealed that this error occurs when dependency csv is at version v1.2.0 or greater (v1.2.1 in the above error), and is irrelevant to the Rust version (tested with Rust 1.67.1, too). When pinned to v1.1.3 (as shown below), the build succeeded.

--- a/fst-bin/Cargo.toml
+++ b/fst-bin/Cargo.toml
@@ -26,7 +26,7 @@ bit-set = "0.5.1"
 bstr = "0.2.11"
 clap = { version = "2.33.0", default-features = false }
 crossbeam-channel = "0.4.2"
-csv = "1.1.3"
+csv = "=1.1.3"
 fst = { version = "0.4.6", features = ["levenshtein"] }
 memmap = "0.7"
 num_cpus = "1.5"

[BurntSushi]

This was fixed in https://github.com/BurntSushi/fst/commit/11b1e3ba79dfa7f469af0236a8d5af1d5cf4a5e3, and the commit message explains why it broke. But I didn't put out a new release of fst-bin. I can do that now.

I also didn't realize people were using fst-bin. And note that it isn't the fst crate that fails, it's the "debug" command line tool that comes with it and is really a separate thing.

[BurntSushi]

This should be fixed in fst-bin 0.4.3 on crates.io.

[ZhongRuoyu]

Thanks for the quick response (and the new release)!

[ZhongRuoyu]

And sorry for missing that commit. I was specifically looking at the history of fst-bin/src/util.rs, but as it turns out, that was the wrong direction.

[BurntSushi]

Yeah it's a subtle failure. It results from Cargo doing feature unification which can easily be inadvertently be depended on, as happened here, unfortunately.