But I wonder if there is any way to manually construct the table, I saw a place where we have a use case to build a two way Map, I wonder if it could be done without duplicating all the stuff.

pub(crate) struct NamedColorMap {
    name_to_rgba: HashMap<&'static str, [u8; 4]>,
    rgba_to_name: HashMap<[u8; 4], &'static str>,
}

This is theoretically possible, however constifying the map generator code isn't trivial. Have a look. A glance there's a lot of code here that depends on non-const APIs:

• random number generation (albeit using a PRNG with a fixed seed which can be constified)
• dynamic allocation with vec![], but with theoretically fixed upper bounds that could be replaced by arrays.
• iteration (but could be replaced by looping with incrementing indices, which are allowed in const)
• invocations of the PhfHash trait (via phf_shared::hash)
• sorting (which requires a trait or closure but could be constified)

It's the trait-based hashing that would be the most difficult to replace right now because we don't have const trait fns. Constifying this would probably require hand-monomorphized code and a different constructor function for each possible key type (deduplicated with macros, sure, but that's suboptimal).

rust-lang/rfcs#2632 would likely allow this, assuming some trait impls get constified as well.

I dont think that a similar RFC is gonna ever come out and be merged in within a year. Maybe #242 is a good step on just making it work with the current hacks that Rust permits.