summaryrefslogtreecommitdiff
path: root/contrib/coccinelle
AgeCommit message (Collapse)AuthorFilesLines
2019-12-01Merge branch 'jk/remove-sha1-to-hex'Libravatar Junio C Hamano1-32/+0
Code clean-up. * jk/remove-sha1-to-hex: hex: drop sha1_to_hex() hex: drop sha1_to_hex_r()
2019-11-13hex: drop sha1_to_hex()Libravatar Jeff King1-15/+0
There's only a single caller left of sha1_to_hex(), since everybody that has an object name in "unsigned char[]" now uses hash_to_hex() instead. This case is in the sha1dc wrapper, where we print a hex sha1 when we find a collision. This one will always be sha1, regardless of the current hash algorithm, so we can't use hash_to_hex() here. In practice we'd probably not be running sha1 at all if it isn't the current algorithm, but it's possible we might still occasionally need to compute a sha1 in a post-sha256 world. Since sha1_to_hex() is just a wrapper for hash_to_hex_algop(), let's call that ourselves. There's value in getting rid of the sha1-specific wrapper to de-clutter the global namespace, and to make sure nobody uses it (and as with sha1_to_hex_r() in the previous patch, we'll drop the coccinelle transformations, too). The sha1_to_hex() function is mentioned in a comment; we can easily swap that out for oid_to_hex() to give a better example. Also update the comment that was left stale when we added "struct object_id *" as a way to name an object and added functions to convert it to hex. The function is also mentioned in some test vectors in t4100, but that's not runnable code, so there's no point in trying to clean it up. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11hex: drop sha1_to_hex_r()Libravatar Jeff King1-17/+0
There are no callers left; everybody uses oid_to_hex_r() or hash_to_hex_algop_r(). This used to actually be the underlying implementation for oid_to_hex_r(), but that's no longer the case since 47edb64997 (hex: introduce functions to print arbitrary hashes, 2018-11-14). Let's get rid of it to de-clutter and to make sure nobody uses it. Likewise we can drop the coccinelle rules that mention it, since the compiler will make it quite clear that the code does not work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in code commentsLibravatar Elijah Newren1-1/+1
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07coccicheck: detect hashmap_entry.hash assignmentLibravatar Eric Wong1-0/+16
Assigning hashmap_entry.hash manually leaves hashmap_entry.next uninitialized, which can be dangerous once the hashmap_entry is inserted into a hashmap. Detect those assignments and use hashmap_entry_init, instead. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-17coccinelle: use COPY_ARRAY for copying arraysLibravatar René Scharfe1-15/+46
The current semantic patch for COPY_ARRAY transforms memcpy(3) calls on pointers, but Coccinelle distinguishes them from arrays. It already contains three rules to handle the options for sizeof (i.e. source, destination and type), and handling arrays as source and destination would require four times as many rules if we enumerated all cases. We also don't handle array subscripts, and supporting that would increase the number of rules by another factor of four. (An isomorphism telling Coccinelle that "sizeof x[...]" is equivalent to "sizeof *x" would be nice..) Support arrays and array subscripts, but keep the number of rules down by adding normalization steps: First turn array subscripts into derefences, then determine the types of expressions used with sizeof and replace them with these types, and then convert the different possible combinations of arrays and pointers with memcpy(3) to COPY_ARRAY. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-09Merge branch 'nd/sha1-name-c-wo-the-repository'Libravatar Junio C Hamano1-7/+13
Further code clean-up to allow the lowest level of name-to-object mapping layer to work with a passed-in repository other than the default one. * nd/sha1-name-c-wo-the-repository: (34 commits) sha1-name.c: remove the_repo from get_oid_mb() sha1-name.c: remove the_repo from other get_oid_* sha1-name.c: remove the_repo from maybe_die_on_misspelt_object_name submodule-config.c: use repo_get_oid for reading .gitmodules sha1-name.c: add repo_get_oid() sha1-name.c: remove the_repo from get_oid_with_context_1() sha1-name.c: remove the_repo from resolve_relative_path() sha1-name.c: remove the_repo from diagnose_invalid_index_path() sha1-name.c: remove the_repo from handle_one_ref() sha1-name.c: remove the_repo from get_oid_1() sha1-name.c: remove the_repo from get_oid_basic() sha1-name.c: remove the_repo from get_describe_name() sha1-name.c: remove the_repo from get_oid_oneline() sha1-name.c: add repo_interpret_branch_name() sha1-name.c: remove the_repo from interpret_branch_mark() sha1-name.c: remove the_repo from interpret_nth_prior_checkout() sha1-name.c: remove the_repo from get_short_oid() sha1-name.c: add repo_for_each_abbrev() sha1-name.c: store and use repo in struct disambiguate_state sha1-name.c: add repo_find_unique_abbrev_r() ...
2019-04-16commit.c: add repo_get_commit_tree()Libravatar Nguyễn Thái Ngọc Duy1-3/+3
Remove the implicit dependency on the_repository in this function. It will be used in sha1-name.c functions when they are updated to take any 'struct repository'. get_commit_tree() remains as a compat wrapper, to be slowly replaced later. Any access to "maybe_tree" field directly will result in _broken_ code after running through commit.cocci because we can't know what is the right repository to use. the_repository would be correct most of the time. But we're relying less and less on the_repository and that assumption may no longer be true. The transformation now is more of a poor man replacement for a C++ compiler catching access to private fields. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-16commit.cocci: refactor code, avoid double rewriteLibravatar Nguyễn Thái Ngọc Duy1-7/+13
"maybe" pointer in 'struct commit' is tricky because it can be lazily initialized to take advantage of commit-graph if available. This makes it not safe to access directly. This leads to a rule in commit.cocci to rewrite 'x->maybe_tree' to 'get_commit_tree(x)'. But that rule alone could lead to incorrectly rewrite assignments, e.g. from x->maybe_tree = yes to get_commit_tree(x) = yes Because of this we have a second rule to revert this effect. Szeder found out that we could do better by performing the assignment rewrite rule first, then the remaining is read-only access and handled by the current first rule. For this to work, we need to transform "x->maybe_tree = y" to something that does NOT contain "x->maybe_tree" to avoid the original first rule. This is where set_commit_tree() comes in. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-04cocci: FLEX_ALLOC_MEM to FLEX_ALLOC_STRLibravatar Denton Liu1-0/+13
Ensure that a FLEX_MALLOC_MEM that uses 'strlen' for its 'len' uses FLEX_ALLOC_STR instead, since these are equivalent forms. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-05Merge branch 'sg/strbuf-addbuf-cocci'Libravatar Junio C Hamano1-0/+30
Cocci rule update. * sg/strbuf-addbuf-cocci: strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other
2019-02-05Merge branch 'sb/more-repo-in-api'Libravatar Junio C Hamano1-0/+144
The in-core repository instances are passed through more codepaths. * sb/more-repo-in-api: (23 commits) t/helper/test-repository: celebrate independence from the_repository path.h: make REPO_GIT_PATH_FUNC repository agnostic commit: prepare free_commit_buffer and release_commit_memory for any repo commit-graph: convert remaining functions to handle any repo submodule: don't add submodule as odb for push submodule: use submodule repos for object lookup pretty: prepare format_commit_message to handle arbitrary repositories commit: prepare logmsg_reencode to handle arbitrary repositories commit: prepare repo_unuse_commit_buffer to handle any repo commit: prepare get_commit_buffer to handle any repo commit-reach: prepare in_merge_bases[_many] to handle any repo commit-reach: prepare get_merge_bases to handle any repo commit-reach.c: allow get_merge_bases_many_0 to handle any repo commit-reach.c: allow remove_redundant to handle any repo commit-reach.c: allow merge_bases_many to handle any repo commit-reach.c: allow paint_down_to_common to handle any repo commit: allow parse_commit* to handle any repo object: parse_object to honor its repository argument object-store: prepare has_{sha1, object}_file to handle any repo object-store: prepare read_object_file to deal with any repo ...
2019-01-27strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an otherLibravatar SZEDER Gábor1-0/+30
The best way to add one strbuf to an other is via: strbuf_addbuf(&sb, &sb2); This is a bit more idiomatic and efficient than: strbuf_addstr(&sb, sb2.buf); because the size of the second strbuf is known and thus it can spare a strlen() call, and much more so than: strbuf_addf(&sb, "%s", sb2.buf); because it can spare the whole vsnprintf() formatting magic. Add new semantic patches to 'contrib/coccinelle/strbuf.cocci' to catch these undesired patterns and to suggest strbuf_addbuf() instead. Luckily, our codebase is already clean from any such undesired patterns (but one of the in-flight topics just tried to sneak in such a strbuf_addf() call). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-15cache: make oidcpy always copy GIT_MAX_RAWSZ bytesLibravatar brian m. carlson1-30/+0
There are some situations in which we want to store an object ID into struct object_id without the_hash_algo necessarily being set correctly. One such case is when cloning a repository, where we must read refs from the remote side without having a repository from which to read the preferred algorithm. In this cases, we may have the_hash_algo set to SHA-1, which is the default, but read refs into struct object_id that are SHA-256. When copying these values, we will want to copy them completely, not just the first 20 bytes. Consequently, make sure that oidcpy copies the maximum number of bytes at all times, regardless of the setting of the_hash_algo. Since oidcpy and hashcpy are no longer functionally identical, remove the Cocinelle object_id transformations that convert from one into the other. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14pretty: prepare format_commit_message to handle arbitrary repositoriesLibravatar Stefan Beller1-0/+10
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: prepare logmsg_reencode to handle arbitrary repositoriesLibravatar Stefan Beller1-0/+9
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: prepare repo_unuse_commit_buffer to handle any repoLibravatar Stefan Beller1-0/+8
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: prepare get_commit_buffer to handle any repoLibravatar Stefan Beller1-0/+8
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit-reach: prepare in_merge_bases[_many] to handle any repoLibravatar Stefan Beller1-0/+17
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit-reach: prepare get_merge_bases to handle any repoLibravatar Stefan Beller1-0/+26
Similarly to previous patches, the get_merge_base functions are used often in the code base, which makes migrating them hard. Implement the new functions, prefixed with 'repo_' and hide the old functions behind a wrapper macro. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14commit: allow parse_commit* to handle any repoLibravatar Stefan Beller1-0/+24
Just like the previous commit, parse_commit and friends are used a lot and are found in new patches, so we cannot change their signature easily. Re-introduce these function prefixed with 'repo_' that take a repository argument and keep the original as a shallow macro. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14object-store: prepare has_{sha1, object}_file to handle any repoLibravatar Stefan Beller1-0/+30
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14object-store: prepare read_object_file to deal with any repoLibravatar Stefan Beller1-0/+12
As read_object_file is a widely used function (which is also regularly used in new code in flight between master..pu), changing its signature is painful is hard, as other series in flight rely on the original signature. It would burden the maintainer if we'd just change the signature. Introduce repo_read_object_file which takes the repository argument, and hide the original read_object_file as a macro behind NO_THE_REPOSITORY_COMPATIBILITY_MACROS, similar to e675765235 (diff.c: remove implicit dependency on the_index, 2018-09-21) Add a coccinelle patch to convert existing callers, but do not apply the resulting patch to keep the diff of this patch small. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14coccicheck: introduce 'pending' semantic patchesLibravatar SZEDER Gábor1-0/+41
Teach `make coccicheck` to avoid patches named "*.pending.cocci" and handle them separately in a new `make coccicheck-pending` instead. This means that we can separate "critical" patches from "FYI" patches. The former target can continue causing Travis to fail its static analysis job, while the latter can let us keep an eye on ongoing (pending) transitions without them causing too much fallout. Document the intended use-cases around these two targets. As the process around the pending patches is not yet fully explored, leave that out. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Based-on-work-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30Merge branch 'jc/cocci-preincr'Libravatar Junio C Hamano1-0/+5
Code cleanup. * jc/cocci-preincr: fsck: s/++i > 1/i++/ cocci: simplify "if (++u > 1)" to "if (u++)"
2018-10-24cocci: simplify "if (++u > 1)" to "if (u++)"Libravatar Junio C Hamano1-0/+5
It is more common to use post-increment than pre-increment when the side effect is the primary thing we want in our code and in C in general (unlike C++). Initializing a variable to 0, incrementing it every time we do something, and checking if we have already done that thing to guard the code to do that thing, is easier to understand when written if (u++) ; /* we've done that! */ else do_it(); /* just once. */ but if you try to use pre-increment, you end up with a less natural looking if (++u > 1) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-15object_id.cocci: match only expressions of type 'struct object_id'Libravatar SZEDER Gábor1-54/+63
Most of our semantic patches in 'contrib/coccinelle/object_id.cocci' turn calls of SHA1-specific functions into calls of their corresponding object_id counterparts, e.g. sha1_to_hex() to oid_to_hex(). These semantic patches look something like this: @@ expression E1; @@ - sha1_to_hex(E1.hash) + oid_to_hex(&E1) and match the access to the 'hash' field in any data type, not only in 'struct object_id', and, consquently, can produce wrong transformations. Case in point is the recent hash function transition patch "rerere: convert to use the_hash_algo" [1], which, among other things, renamed 'struct rerere_dir's 'sha1' field to 'hash', and then 'make coccicheck' started to suggest the following wrong transformations for 'rerere.c' [2]: - return sha1_to_hex(id->collection->hash); + return oid_to_hex(id->collection); and - DIR *dir = opendir(git_path("rr-cache/%s", sha1_to_hex(rr_dir->hash))); + DIR *dir = opendir(git_path("rr-cache/%s", oid_to_hex(rr_dir))); Avoid such wrong transformations by tightening semantic patches in 'object_id.cocci' to match only type of or pointers to 'struct object_id'. [1] https://public-inbox.org/git/20181008215701.779099-15-sandals@crustytoothpaste.net/ [2] https://travis-ci.org/git/git/jobs/440463476#L580 Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "hashcmp() != 0" to "!hasheq()"Libravatar Jeff King1-0/+9
This rounds out the previous three patches, covering the inequality logic for the "hash" variant of the functions. As with the previous three, the accompanying code changes are the mechanical result of applying the coccinelle patch; see those patches for more discussion. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "oidcmp() != 0" to "!oideq()"Libravatar Jeff King1-0/+6
This is the flip side of the previous two patches: checking for a non-zero oidcmp() can be more strictly expressed as inequality. Like those patches, we write "!= 0" in the coccinelle transformation, which covers by isomorphism the more common: if (oidcmp(E1, E2)) As with the previous two patches, this patch can be achieved almost entirely by running "make coccicheck"; the only differences are manual line-wrap fixes to match the original code. There is one thing to note for anybody replicating this, though: coccinelle 1.0.4 seems to miss the case in builtin/tag.c, even though it's basically the same as all the others. Running with 1.0.7 does catch this, so presumably it's just a coccinelle bug that was fixed in the interim. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "hashcmp() == 0" to hasheq()Libravatar Jeff King1-0/+9
This is the partner patch to the previous one, but covering the "hash" variants instead of "oid". Note that our coccinelle rule is slightly more complex to avoid triggering the call in hasheq(). I didn't bother to add a new rule to convert: - hasheq(E1->hash, E2->hash) + oideq(E1, E2) Since these are new functions, there won't be any such existing callers. And since most of the code is already using oideq, we're not likely to introduce new ones. We might still see "!hashcmp(E1->hash, E2->hash)" from topics in flight. But because our new rule comes after the existing ones, that should first get converted to "!oidcmp(E1, E2)" and then to "oideq(E1, E2)". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "oidcmp() == 0" to oideq()Libravatar Jeff King1-0/+6
Using the more restrictive oideq() should, in the long run, give the compiler more opportunities to optimize these callsites. For now, this conversion should be a complete noop with respect to the generated code. The result is also perhaps a little more readable, as it avoids the "zero is equal" idiom. Since it's so prevalent in C, I think seasoned programmers tend not to even notice it anymore, but it can sometimes make for awkward double negations (e.g., we can drop a few !!oidcmp() instances here). This patch was generated almost entirely by the included coccinelle patch. This mechanical conversion should be completely safe, because we check explicitly for cases where oidcmp() is compared to 0, which is what oideq() is doing under the hood. Note that we don't have to catch "!oidcmp()" separately; coccinelle's standard isomorphisms make sure the two are treated equivalently. I say "almost" because I did hand-edit the coccinelle output to fix up a few style violations (it mostly keeps the original formatting, but sometimes unwraps long lines). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29coccinelle: use <...> for function exclusionLibravatar Jeff King2-12/+12
Sometimes we want to suppress a coccinelle transformation inside a particular function. For example, in finding conversions of hashcmp() to oidcmp(), we should not convert the call in oidcmp() itself, since that would cause infinite recursion. We write that like this: @@ identifier f != oidcmp; expression E1, E2; @@ f(...) {... - hashcmp(E1->hash, E2->hash) + oidcmp(E1, E2) ...} to match the interior of any function _except_ oidcmp(). Unfortunately, this doesn't catch all cases (e.g., the one in sequencer.c that this patch fixes). The problem, as explained by one of the Coccinelle developers in [1], is: For transformation, A ... B requires that B occur on every execution path starting with A, unless that execution path ends up in error handling code. (eg, if (...) { ... return; }). Here your A is the start of the function. So you need a call to hashcmp on every path through the function, which fails when you add ifs. [...] Another issue with A ... B is that by default A and B should not appear in the matched region. So your original rule matches only the case where every execution path contains exactly one call to hashcmp, not more than one. One way to solve this is to put the pattern inside an angle-bracket pattern like "<... P ...>", which allows zero or more matches of P. That works (and is what this patch does), but it has one drawback: it matches more than we care about, and Coccinelle uses extra CPU. Here are timings for "make coccicheck" before and after this patch: [before] real 1m27.122s user 7m34.451s sys 0m37.330s [after] real 2m18.040s user 10m58.310s sys 0m41.549s That's not ideal, but it's more important for this to be correct than to be fast. And coccicheck is already fairly slow (and people don't run it for every single patch). So it's an acceptable tradeoff. There _is_ a better way to do it, which is to record the position at which we find hashcmp(), and then check it against the forbidden function list. Like: @@ position p : script:python() { p[0].current_element != "oidcmp" }; expression E1,E2; @@ - hashcmp@p(E1->hash, E2->hash) + oidcmp(E1, E2) This is only a little slower than the current code, and does the right thing in all cases. Unfortunately, not all builds of Coccinelle include python support (including the ones in Debian). Requiring it may mean that fewer people can easily run the tool, which is worse than it simply being a little slower. We may want to revisit this decision in the future if: - builds with python become more common - we find more uses for python support that tip the cost-benefit analysis But for now this patch sticks with the angle-bracket solution, and converts all existing cocci patches. This fixes only one missed case in the current code, though it makes a much better difference for some new rules I'm adding (converting "!hashcmp()" to "hasheq()" misses over half the possible conversions using the old form). [1] https://public-inbox.org/git/alpine.DEB.2.21.1808240652370.2344@hadrien/ Helped-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16coccinelle: update commit.cocciLibravatar Derrick Stolee1-1/+1
A recent patch series renamed the get_commit_tree_from_graph method but forgot to update the coccinelle script that exempted it from rules regarding accesses to 'maybe_tree'. This fixes that oversight to bring the coccinelle scripts back to a good state. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02coccinelle: avoid wrong transformation suggestions from commit.cocciLibravatar SZEDER Gábor1-6/+4
The semantic patch 'contrib/coccinelle/commit.cocci' added in 2e27bd7731 (treewide: replace maybe_tree with accessor methods, 2018-04-06) is supposed to "ensure that all references to the 'maybe_tree' member of struct commit are either mutations or accesses through get_commit_tree()". So get_commit_tree() clearly must be able to directly access the 'maybe_tree' member, and 'commit.cocci' has a bit of a roundabout workaround to ensure that get_commit_tree()'s direct access in its return statement is not transformed: after all references to 'maybe_tree' have been transformed to a call to get_commit_tree(), including the reference in get_commit_tree() itself, the last rule transforms back a 'return get_commit_tree()' statement, back then found only in get_commit_tree() itself, to a direct access. Unfortunately, already the very next commit shows that this workaround is insufficient: 7b8a21dba1 (commit-graph: lazy-load trees for commits, 2018-04-06) extends get_commit_tree() with a condition directly accessing the 'maybe_tree' member, and Coccinelle with 'commit.cocci' promptly detects it and suggests a transformation to avoid it. This transformation is clearly wrong, because calling get_commit_tree() to access 'maybe_tree' _in_ get_commit_tree() would obviously lead to recursion. Furthermore, the same commit added another, more specialized getter function get_commit_tree_in_graph(), whose legitimate direct access to 'maybe_tree' triggers a similar wrong transformation suggestion. Exclude both of these getter functions from the general rule in 'commit.cocci' that matches their direct accesses to 'maybe_tree'. Also exclude load_tree_for_commit(), which, as static helper funcion of get_commit_tree_in_graph(), has legitimate direct access to 'maybe_tree' as well. The last rule transforming back 'return get_commit_tree()' statements to direct accesses thus became unnecessary, remove it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11treewide: replace maybe_tree with accessor methodsLibravatar Derrick Stolee1-0/+30
In anticipation of making trees load lazily, create a Coccinelle script (contrib/coccinelle/commit.cocci) to ensure that all references to the 'maybe_tree' member of struct commit are either mutations or accesses through get_commit_tree() or get_commit_tree_oid(). Apply the Coccinelle script to create the rest of the patch. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-15Merge branch 'rs/cocci-strbuf-addf-to-addstr'Libravatar Junio C Hamano1-16/+1
* rs/cocci-strbuf-addf-to-addstr: cocci: simplify check for trivial format strings
2018-02-02cocci: simplify check for trivial format stringsLibravatar René Scharfe1-16/+1
353d84c537 (coccicheck: make transformation for strbuf_addf(sb, "...") more precise) added a check to avoid transforming calls with format strings which contain percent signs, as that would change the result. It uses embedded Python code for that. Simplify this rule by using the regular expression matching operator instead. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19cocci: use format keyword instead of a literal stringLibravatar René Scharfe1-1/+2
There's a rule in strbuf.cocci for converting trivial uses of strbuf_addf() to strbuf_addstr() in order to simplify the code and improve performance a bit. Coccinelle 1.0.0~rc19.deb-3 on Travis CI lets the "%s" in that rule match format strings like "%d" as well for some reason, though, leading to invalid proposed patches. Use the "format" keyword to let Coccinelle parse the format string and match the conversion specifier with a trivial regular expression instead. This works fine with both Coccinelle 1.0.0~rc19.deb-3 and 1.0.4.deb-3+b3 (the current version on Debian testing). Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Tested-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02coccinelle: remove parentheses that become unnecessaryLibravatar René Scharfe1-5/+5
Transformations that hide multiplications can end up with an pair of parentheses that is no longer needed. E.g. with a rule like this: @@ expression E; @@ - E * 2 + double(E) ... we might get a patch like this: - x = (a + b) * 2; + x = double((a + b)); Add a pair of parentheses to the preimage side of such rules. Coccinelle will generate patches that remove them if they are present, and it will still match expressions that lack them. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17add MOVE_ARRAYLibravatar René Scharfe1-0/+17
Similar to COPY_ARRAY (introduced in 60566cbb58), add a safe and convenient helper for moving potentially overlapping ranges of array entries. It infers the element size, multiplies automatically and safely to get the size in bytes, does a basic type safety check by comparing element sizes and unlike memmove(3) it supports NULL pointers iff 0 elements are to be moved. Also add a semantic patch to demonstrate the helper's intended usage. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-29coccinelle: polish FREE_AND_NULL rulesLibravatar René Scharfe1-9/+1
There are two rules for using FREE_AND_NULL in free.cocci, one for pointer types and one for expressions. Both cause coccinelle to remove empty lines and even newline characters between replacements for some reason; consecutive "free(x);/x=NULL;" sequences end up as multiple FREE_AND_NULL calls on the same time. Remove the type rule, as the expression rule already covers it, and rearrange the lines of the latter to place the addition of FREE_AND_NULL between the removals, which causes coccinelle to leave surrounding whitespace untouched. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-16coccinelle: add a rule to make "expression" code use FREE_AND_NULL()Libravatar Ævar Arnfjörð Bjarmason1-0/+7
A follow-up to the existing "type" rule added in an earlier change. This catches some occurrences that are missed by the previous rule. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-16coccinelle: add a rule to make "type" code use FREE_AND_NULL()Libravatar Ævar Arnfjörð Bjarmason1-0/+8
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-10Merge branch 'rs/strbuf-add-real-path'Libravatar Junio C Hamano2-0/+22
An helper function to make it easier to append the result from real_path() to a strbuf has been added. * rs/strbuf-add-real-path: strbuf: add strbuf_add_real_path() cocci: use ALLOC_ARRAY
2017-02-27strbuf: add strbuf_add_real_path()Libravatar René Scharfe1-0/+6
Add a function for appending the canonized absolute pathname of a given path to a strbuf. It keeps the existing contents intact, as expected of a function of the strbuf_add() family, while avoiding copying the result if the given strbuf is empty. It's more consistent with the rest of the strbuf API than strbuf_realpath(), which it's wrapping. Also add a semantic patch demonstrating its intended usage and apply it to the current tree. Using strbuf_add_real_path() instead of calling strbuf_addstr() and real_path() avoids an extra copy to a static buffer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27cocci: use ALLOC_ARRAYLibravatar René Scharfe1-0/+16
Add a semantic patch for using ALLOC_ARRAY to allocate arrays and apply the transformation on the current source tree. The macro checks for multiplication overflow and infers the element size automatically; the result is shorter and safer code. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-16Merge branch 'rs/cocci-check-free-only-null'Libravatar Junio C Hamano1-0/+6
A new coccinelle rule that catches a check of !pointer before the pointer is free(3)d, which most likely is a bug. * rs/cocci-check-free-only-null: cocci: detect useless free(3) calls
2017-02-15Merge branch 'rs/swap'Libravatar Junio C Hamano1-0/+28
Code clean-up. * rs/swap: graph: use SWAP macro diff: use SWAP macro use SWAP macro apply: use SWAP macro add SWAP macro
2017-02-11cocci: detect useless free(3) callsLibravatar René Scharfe1-0/+6
Add a semantic patch for removing checks that cause free(3) to only be called with a NULL pointer, as that must be a programming mistake. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-02Merge branch 'rs/absolute-pathdup'Libravatar Junio C Hamano1-0/+6
Code cleanup. * rs/absolute-pathdup: use absolute_pathdup() abspath: add absolute_pathdup()