indexmap 1.6.2 breaks some crates: <null> error:0:Omitted type parameter with no default in ::"indexmap-1_6_2"::set::IndexSet

[barracuda156]

Examples, using mrustc:

--- BUILDING object v0.25.2 (29.6% 1r,42w,119b,68c/230t)
> /opt/local/libexec/mrustc/bin/mrustc rustc-1.54.0-src/vendor/object/src/[lib.rs](http://lib.rs/) -o output-1.54.0/rustc-build/libobject-0_25_2_H662bb14.rlib -C emit-depfile=output-1.54.0/rustc-build/libobject-0_25_2_H662bb14.rlib.d --cfg debug_assertions -O -L output-1.54.0 -L output-1.54.0/rustc-build --cfg feature="read_core" --cfg feature="elf" --cfg feature="macho" --cfg feature="pe" --cfg feature="unaligned" --cfg feature="archive" --cfg feature="write" --cfg feature="coff" --cfg feature="write_core" --cfg feature="crc32fast" --cfg feature="indexmap" --cfg feature="std" --cfg feature="dep:crc32fast" --cfg feature="dep:indexmap" --cfg feature="memchr" --cfg feature="dep:memchr" --crate-name object --crate-type rlib --crate-tag 0_25_2_H662bb14 --edition 2018 --extern crc32fast=output-1.54.0/rustc-build/libcrc32fast-1_2_1_H20.rlib --extern indexmap=output-1.54.0/rustc-build/libindexmap-1_6_2.rlib --extern memchr=output-1.54.0/rustc-build/libmemchr-2_4_0_Hc.rlib > output-1.54.0/rustc-build/libobject-0_25_2_H662bb14.rlib_dbg.txt
 (29.6% 1r,42w,119b,68c/230t): object v0.25.2
<null> error:0:Omitted type parameter with no default in ::"indexmap-1_6_2"::set::IndexSet<&'I0 [u8],>
Process was terminated with signal 6

--- BUILDING petgraph v0.5.1 (31.3% 1r,39w,118b,72c/230t)
> /opt/local/libexec/mrustc/bin/mrustc rustc-1.54.0-src/vendor/petgraph/src/[lib.rs](http://lib.rs/) -o output-1.54.0/rustc-build/libpetgraph-0_5_1_H4090.rlib -C emit-depfile=output-1.54.0/rustc-build/libpetgraph-0_5_1_H4090.rlib.d --cfg debug_assertions -O -L output-1.54.0 -L output-1.54.0/rustc-build --cfg feature="graphmap" --cfg feature="stable_graph" --cfg feature="matrix_graph" --crate-name petgraph --crate-type rlib --crate-tag 0_5_1_H4090 --edition 2018 --extern fixedbitset=output-1.54.0/rustc-build/libfixedbitset-0_2_0.rlib --extern indexmap=output-1.54.0/rustc-build/libindexmap-1_6_2.rlib > output-1.54.0/rustc-build/libpetgraph-0_5_1_H4090.rlib_dbg.txt
 (31.3% 1r,39w,118b,72c/230t): petgraph v0.5.1
<null> error:0:Omitted type parameter with no default in ::"indexmap-1_6_2"::set::IndexSet<usize,>
Process was terminated with signal 6
FAILING COMMAND: /opt/local/libexec/mrustc/bin/mrustc rustc-1.54.0-src/vendor/petgraph/src/[lib.rs](http://lib.rs/) -o output-1.54.0/rustc-build/libpetgraph-0_5_1_H4090.rlib -C emit-depfile=output-1.54.0/rustc-build/libpetgraph-0_5_1_H4090.rlib.d --cfg debug_assertions -O -L output-1.54.0 -L output-1.54.0/rustc-build --cfg feature="graphmap" --cfg feature="stable_graph" --cfg feature="matrix_graph" --crate-name petgraph --crate-type rlib --crate-tag 0_5_1_H4090 --edition 2018 --extern fixedbitset=output-1.54.0/rustc-build/libfixedbitset-0_2_0.rlib --extern indexmap=output-1.54.0/rustc-build/libindexmap-1_6_2.rlib

Maybe this has been fixed in later versions? I am trying to bootstrap Rust 1.54, and there 1.6.2 is used.

[barracuda156]

@cuviper Could you please take a look?

[cuviper]

The 1.x series was a bit messy with the std/no_std support, and std is required to get a default S parameter. Roughly:

• 1.0 always required std, so there was always a default S = RandomState.
• 1.3 tried to support #[no_std] without breaking any existing default-features = false users, as they might still expect that S. So we tried to auto-detect if the current target had actual std support or not. If not, S had no default.
• 1.5.2 added an explicit "std" feature to force it on, bypassing the auto-detection.
• 2.0 changed to the explicit feature only, removing the auto-detection.

So it seems you're getting a build that fails to detect std support, but has code that expects the default S anyway. Having mrustc in the mix might well be why that detection failed. If you can force the indexmap/std feature to be enabled anywhere in that workspace, that might be enough to get you working again.

[cuviper]

Closing because I don't think there's anything we can do to fix 1.x. Feel free to ask any followup questions though!