[libc][wctype] Missing hash table needed for case conversions

[bassiounix]

We proposed to use a hash table in the conversion section in RFC https://discourse.llvm.org/t/rfc-libc-wctype-header-implementation/88941.
However, there isn't a suitable hash table implementation in LLVM libc. The existing hash table class was meant for the public htable functions which don't have a convenient API for internal LLVM-libc use which handle entries with char* keys and void* values.

What we need is a compile-time constexpr hash table that maps wint_t key to wint_t value.
The only operations we need from this specific implementation is to:

• Retrieve entry with a given key.
• Validate whether a key exists in the hash table.
• Construct and build the table at compile time from the generated data.

Since we need a specific type we don't necessary need templates. Also the size of the table would be tied to the conversion tables only (which is around 1460 max at the time of writing this issue).

Given the above, a custom hash table written from scratch for this specific use case is the way to go.

[llvmbot]

@llvm/issue-subscribers-libc

Author: Muhammad Bassiouni (bassiounix)

We proposed to use a hash table in the conversion section in RFC <https://discourse.llvm.org/t/rfc-libc-wctype-header-implementation/88941>. However, there isn't a suitable hash table implementation in LLVM libc. The existing hash table class was meant for the public htable functions which don't have a convenient API for internal LLVM-libc use which handle entries with `char*` keys and `void*` values.

What we need is a compile-time constexpr hash table that maps wint_t key to wint_t value.
The only operations we need from this specific implementation is to:

• Retrieve entry with a given key.
• Validate whether a key exists in the hash table.
• Construct and build the table at compile time from the generated data.

Since we need a specific type we don't necessary need templates. Also the size of the table would be tied to the conversion tables only (which is around 1460 max at the time of writing this issue).

Given the above, a custom hash table written from scratch for this specific use case is the way to go.