On Wed, Mar 22 2023, Glen Choo wrote: > Glen Choo <chooglen@xxxxxxxxxx> writes: > >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >>> diff --git a/contrib/coccinelle/the_repository.pending.cocci b/contrib/coccinelle/the_repository.pending.cocci >>> deleted file mode 100644 >>> index 1190a3312bd..00000000000 >>> --- a/contrib/coccinelle/the_repository.pending.cocci >>> +++ /dev/null >>> @@ -1,14 +0,0 @@ >>> -// This file is used for the ongoing refactoring of >>> -// bringing the index or repository struct in all of >>> -// our code base. >> We can't go so far as to say that we've removed all implicit references >> to "the_repository", though, since we still have functions that >> reference "the_repository" in their implementations. But, I don't think >> this ".cocci" file would help us with those cases anyway, since this was >> targeted specifically at functions/macros that were passing >> "the_repository" to functions that accepted a "struct repository" arg. > > For these implicitly-the_repository functions, (e.g. git_path) we'd > presumably refactor them into repo_* versions and then apply the same > sorts of changes we did in this series? I guess we'd make those changes > in contrib/coccinelle/the_repository.cocci, so we don't need the > *.pending* one. Whether we add it to a "pending" or not is just a question of whether the migration is done right away, or left for later. > On that note, I'm curious what contrib/coccinelle/the_repository.cocci > is doing for us after this series. By definition, all of the macros have > been fully migrated, so they're all a noop. I left them for the benefit of any in-flight conflicts, or semantic conflicts with out-of-tree. I.e. in such a case you'd keep the other side, then apply the cocci rule, and the result is a semantically correct merge of the two. > Would this slow down `make coccicheck`? A bit. It doesn't slow it down by much, as these rules are the simplest to execute, spatch can skip the file if the relevant tokens aren't found in it.
