git/khash.h, branch jch

hash-ll, hashmap: move oidhash() to hash-ll

2023-06-21T20:39:54Z

oidhash() was used by both hashmap and khash, which makes sense. However, the location of this function in hashmap.[ch] meant that khash.h had to depend upon hashmap.h, making people unfamiliar with khash think that it was built upon hashmap. (Or at least, I personally was confused for a while about this in the past.) Move this function to hash-ll, so that khash.h can stop depending upon hashmap.h. This has another benefit as well: it allows us to remove hashmap.h's dependency on hash-ll.h. While some callers of hashmap.h were making use of oidhash, most were not, so this change provides another way to reduce the number of includes. Diff best viewed with `--color-moved`. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

khash: name the structs that khash declares

2023-06-21T20:39:54Z

khash.h lets you instantiate custom hash types that map between two types. These are defined as a struct, as you might expect, and khash typedef's that to kh_foo_t. But it declares the struct anonymously, which doesn't give a name to the struct type itself; there is no "struct kh_foo". This has two small downsides: - when using khash, we declare "kh_foo_t *the_foo". This is unlike our usual naming style, which is "struct kh_foo *the_foo". - you can't forward-declare a typedef of an unnamed struct type in C. So we might do something like this in a header file: struct kh_foo; struct bar { struct kh_foo *the_foo; }; to avoid having to include the header that defines the real kh_foo. But that doesn't work with the typedef'd name. Without the "struct" keyword, the compiler doesn't know we mean that kh_foo is a type. So let's always give khash structs the name that matches our conventions ("struct kh_foo" to match "kh_foo_t"). We'll keep doing the typedef to retain compatibility with existing callers. Co-authored-by: Jeff King Signed-off-by: Jeff King Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

hash-ll.h: split out of hash.h to remove dependency on repository.h

2023-04-24T19:47:32Z

hash.h depends upon and includes repository.h, due to the definition and use of the_hash_algo (defined as the_repository->hash_algo). However, most headers trying to include hash.h are only interested in the layout of the structs like object_id. Move the parts of hash.h that do not depend upon repository.h into a new file hash-ll.h (the "low level" parts of hash.h), and adjust other files to use this new header where the convenience inline functions aren't needed. This allows hash.h and object.h to be fairly small, minimal headers. It also exposes a lot of hidden dependencies on both path.h (which was brought in by repository.h) and repository.h (which was previously implicitly brought in by object.h), so also adjust other files to be more explicit about what they depend upon. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

treewide: remove unnecessary cache.h includes

2023-02-24T01:25:28Z

We had several header files include cache.h unnecessarily. Remove those. These have all been verified via both ensuring that gcc -E $HEADER | grep '"cache.h"' found no hits and that cat >temp.c < Signed-off-by: Junio C Hamano

khash: clarify that allocations never fail

2021-07-06T20:07:50Z

We use our standard allocation functions and macros (xcalloc, ALLOC_ARRAY, REALLOC_ARRAY) in our version of khash.h. They terminate the program on error instead, so code that's using them doesn't have to handle allocation failures. Make this behavior explicit by turning kh_resize_ into a void function and removing the related unreachable error handling code. Helped-by: Jeff King Signed-off-by: René Scharfe Acked-by: Jeff King Signed-off-by: Junio C Hamano

hashmap: convert sha1hash() to oidhash()

2019-06-20T17:44:22Z

There are no callers left of sha1hash() that do not simply pass the "hash" member of a "struct object_id". Let's get rid of the outdated sha1-specific function and provide one that operates on the whole struct (even though the technique, taking the first few bytes of the hash, will remain the same). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

khash: rename oid helper functions

2019-06-20T17:37:55Z

For use in object_id hash tables, we have oid_hash() and oid_equal(). But these are confusingly similar to the existing oideq() and the oidhash() we plan to add to replace sha1hash(). The big difference from those functions is that rather than accepting a const pointer to the "struct object_id", we take the arguments by value (which is a khash internal convention). So let's make that obvious by calling them oidhash_by_value() and oideq_by_value(). Those names are fairly horrendous to type, but we rarely need to do so; they are passed to the khash implementation macro and then only used internally. Callers get to use the nice kh_put_oid_map(), etc. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

khash: drop sha1-specific map types

2019-06-20T17:37:41Z

All of the callers of khash_sha1 and khash_sha1_pos have been removed, in favor of using maps that use "struct object_id" as their keys. Let's drop these now-obsolete types. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

khash: rename kh_oid_t to kh_oid_set

2019-06-20T17:27:48Z

khash lets us define a hash as either a map or a set (i.e., with no "value" type). For the oid maps we define, "oid" is the set and "oid_map" is the map. As the bug in the previous commit shows, it's easy to pick the wrong one. So let's make the names more distinct: "oid_set" and "oid_map". An alternative naming scheme would be to actually name the type after the key/value types. So e.g., "oid" _would_ be the set, since it has no value type. And "oid_map" would become "oid_void" or similar (and "oid_pos" becomes "oid_int"). That's better in some ways: it's more regular, and a given map type can be more reasily reused in multiple contexts (e.g., something storing an "int" that isn't a "pos"). But it's also slightly less descriptive. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

khash: drop broken oid_map typedef

2019-06-20T17:21:27Z

Commit 5a8643eff1 (khash: move oid hash table definition, 2019-02-19) added a khash "oid_map" type to match the existing "oid" type, which is a simple set (i.e., just keys, no values). But in setting up the khash_oid_map typedef, it accidentally referred to "kh_oid_t", which is the set type. Nobody noticed the breakage because there are not yet any callers; the type was added just as a match to the existing sha1 types (whose map type confusingly _is_ called khash_sha1, and it has no matching set type). We could easily fix this with s/oid/oid_map/ in the typedef. But let's take this a step further, and just drop the typedef entirely. These typedefs were added by 5a8643eff1 to match the khash_sha1 typedefs. But the actual khash-derived type names are descriptive enough; this is just adding an extra layer of indirection. The khash names do not quite follow our usual style (e.g., they end in "_t"), but since we end up using other khash names (e.g., khiter_t, kh_get_oid()) anyway, just typedef-ing the struct name is not really helping much. And there are already many cases where we use the raw khash type names anyway (e.g., the "set" variant defined just above us does not have such a typedef!). So let's drop this typedef, and the matching oid_pos one (which actually _does_ have a user, but we can easily convert it). We'll leave the khash_sha1 typedef around. The ultimate fate of its callers should be conversion to kh_oid_map_t, so there's no point in going through the noise of changing the names now. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano