Panic when using get() on an empty map

[neandrake]

I'm not sure if this is actually supported but I did see #111 and #116 with slight variations of this.

In one of my tests I create an empty map like so

pub static TS_BY_UID: phf::Map<&'static str, TSRef> = phf::Map {
    key: 0,
    disps: ::phf::Slice::Static(&[]),
    entries: ::phf::Slice::Static(&[]),
};

From this bit of code

self.ts = self.ts_by_uid  // self.ts_by_uid ends up being set as TS_BY_UID above
        .get::<str>(ts_uid.as_ref())
        .cloned()
        .ok_or_else(|| {
            Error::new(
                ErrorKind::InvalidData,
                format!("Unknown TransferSyntax: {:?}", ts_uid),
            )
        })?;

Results in this panic

thread 'core::tests::tests::test_dicom_object' panicked at 'attempt to calculate the remainder with a divisor of zero', /Users/cspeckrun/.cargo/registry/src/github.com-1ecc6299db9ec823/phf_shared-0.7.24/src/lib.rs:46:26
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /Users/vsts/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /Users/vsts/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: rust_begin_unwind
             at src/libstd/panicking.rs:311
   9: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  10: core::panicking::panic
             at src/libcore/panicking.rs:49
  11: phf_shared::get_index
             at /Users/cspeckrun/.cargo/registry/src/github.com-1ecc6299db9ec823/phf_shared-0.7.24/src/lib.rs:46
  12: phf::map::Map<K,V>::get_entry
             at /Users/cspeckrun/.cargo/registry/src/github.com-1ecc6299db9ec823/phf-0.7.24/src/map.rs:84
  13: phf::map::Map<K,V>::get
             at /Users/cspeckrun/.cargo/registry/src/github.com-1ecc6299db9ec823/phf-0.7.24/src/map.rs:64
  14: dcmpipe_lib::core::dcmparser::DicomStreamParser<StreamType>::parse_transfer_syntax
             at dcmpipe_lib/src/core/dcmparser.rs:319

[raftario]

This is due to the fact the fix for empty maps has been merged after the latest release. The only way to fix it is to depend on the git repo instead of the Crates.io release.

[neandrake]

Was this fixed by #116 then? I assumed that change would've been in the latest release because it appears to have been merged on January 2018 but it looks like the 0.7.24 release was made nearly a year later in January 2019.

[raftario]

You're right, my bad, I didn't look closely enough at the date and assumed it was in 2019 because the fix wasn't present in the release. However I can confirm it isn't included in 0.7.24, which is really weird. See https://github.com/sfackler/rust-phf/blob/1287414b1302d2d717c5f4be81accf4c12ccad48/phf/src/map.rs#L79-L92

[raftario]

If you look at the history, you can see #116 was actually never merged into master and the fix was only merged a year later in March by #145, shortly after the latest release.

[abonander]

Try the new 0.8.0 release which should have the aforementioned fix.

[neandrake]

This can likely be closed however I am blocked on upgrading to 0.8 due to /pull/185.

[JohnTitor]

Closing as the issue itself has been fixed and released. Thanks!