At the most basic level, this means you can use phf_codegen if you've got something like extern crate phf as __some_phf_alias;. More usefully, this PR permits crates to add their own codegen on top of phf without requiring all consuming crates to explicitly depend on phf.

Concretely, I want this for servo/string-cache#136. See https://github.com/servo/string-cache/pull/136/files#diff-f5597aa77bf5eea303399f7125c5a0adR10 and the current hack I'm resorting to at https://github.com/servo/string-cache/pull/136/files#diff-141f99248469f8dc2a1daf108bbf23c1R71 (relies on the next string being written to start with ::phf).

To briefly explain the problem: it's a given that consumers of string_cache_codegen will need to depend on string_cache. However, if string_cache_codegen generates a vanilla phf map, consumers of string_cache_codegen also need to add phf to their own Cargo.toml and add extern crate phf;. Exposing phf under the string_cache crate sidesteps this inconvenience by using the existing string_cache dependency (and means you don't have to upgrade string_cache and phf in lockstep).

(I'm open to suggestions for better ways to do this by the way)