Open Shizcow opened 1 month ago
When I worked on this years ago, I remember encountering the same issue, which makes it more annoying to use, but it wasn't completely straightforward to fix. Here's what I remember.
constexpr
function, that's kind of the point of this crate. There are constexpr sort routines, but then you are committing frozen to only supporting sort-able keys I guess. And you probably don't want to just do a naive O(n^2) duplicate check because you don't want to have a scenario where the input validation takes longer than the hash table generation.carray
, so it's fairly finicky. I never got to the point of having a working patch -- a big part of working on this code was working through the compiler fight around constexpr.For me this like 6 years ago, maybe the compilers are less finicky about constexpr nowadays. HTH
In my project, I have a large
unordered_map
that I use to store command line debug flags and attributes for those flags. I was performing some copy-paste programming to add a few new flags and accidentally created a map with duplicate keys -- an easy mistake. However, realizing that the duplicate value was present was extremely difficult because there's no tailored error message produced. Instead, frozen seems to happily keep trying new seeds infinitely, expecting the duplicate keys to eventually produce different hash values. This will either run over the constexpr limit or, if the limit is raised, cause GCC to consume all the memory on the system and die. Not a very helpful failure case for determining the root cause of a duplicate key issue.Here's a minimal repro:
This will cause an infinite loop in constexpr evaluation and lead to:
Or if the limit is raised, eventually consuming all system memory and killing GCC.
Is is possible to trigger a more descriptive error message? Even if the exact keys can't be printed out in a diagnostic, something like:
would be immensely helpful in pointing to a solution.