toCritBitTree funcs have wrong signature

[konsumlamm]

The toCritBitTree func (from the critbits module) doesn't work with non-string values.

Example

import critbits

echo {"a": 0, "b": 1}.toCritBitTree

Current Output

Error:

/home/<censored>/Projects/Nim/testing/src/testing.nim(17, 25) template/generic instantiation of `toCritBitTree` from here
/home/<censored>/.choosenim/toolchains/nim-#devel/lib/pure/collections/critbits.nim(538, 28) Error: type mismatch: got <CritBitTree[system.string], string, int>
but expected one of: 
proc incl[T](c: var CritBitTree[T]; key: string; val: T)
  first type mismatch at position: 3
  required type for val: T
  but expression 'item[1]' is of type: int
3 other mismatching symbols have been suppressed; compile with --showAllMismatches:on to see them

expression: incl(result, item[0], item[1])

Expected Output

{"a": 0, "b": 1}

Possible Solution

Currently, the signatures of the toCritBitTree funcs are as follows (https://github.com/nim-lang/Nim/blob/devel/lib/pure/collections/critbits.nim#L534):

func toCritBitTree*[A, B](pairs: openArray[(A, B)]): CritBitTree[A]
func toCritBitTree*[T](items: openArray[T]): CritBitTree[void]

If the result type for the first version is changed to CritBitTree[B], the bug is fixed (since A is the key type and B the value type). However, the generic type parameter for the keys (A and T) is unnecessary in both versions, since CritBitTrees always have string keys. So the fixed signatures should be (the actual implementation doesn't need to change):

func toCritBitTree*[T](pairs: openArray[(string, T)]): CritBitTree[T]
func toCritBitTree*(items: openArray[string]): CritBitTree[void]

This both fixes the bug and produces better error messages when someone attempts to use non-string keys.

Additional Information

This is not a regression, since the code didn't change since it's addition in #15444.

$ nim -v
Nim Compiler Version 1.5.1
git hash: 297c8e403d110dd872e070563328f4e0c734cd01