mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-10-05 17:11:04 +01:00
Chandler CarruthandGeoff Romer
bba037738d
The `ClangDecl` struct caused some confusion here -- it is embedding extra data into a `CanonicalValueStore` that isn't used for lookups or canonicalization, but is useful to store along side. This changes the `CanonicalValueStore` to support customized key type for `Lookup` so that we can provide the more direct API that only takes the relevant key. This in turn takes advantage of the support for heterogenous keys in the underlying `Set` as long as hashing and equality are consistent. We do need to add support for heterogenous equality comparison with `clang::Decl*`, but that is fairly easily done now that the argument-reversed form isn't needed as well. Lastly, this cleans up the `ClangDecl` customization points to be more idiomatic by using `operator==` and `CarbonHashValue`. While there, I've added comments to make it unambiguous why we can use the pointer value for the underlying `clang::Decl` due to the Clang AST's address-as-identity model. Resolves the immediate TODOs around this type. Future work might involve changing from the current `Add` API to one more like `Map` and `Set`'s API where a callback is used to create the object, but that level of API complexity isn't necessarily motivated yet and can easily be a follow-on if and when its worth doing. The `Add` code paths *are* working with the `inst_id` in order to create an instruction if we are importing the Clang declaration. It is the `Lookup` code paths that never needed to know about the `inst_id` and became more confusing for having to stub it out in the API. --------- Co-authored-by: Geoff Romer <gromer@google.com>