Beat Bolli <dev+git@xxxxxxxxx> writes:
> The marco GIT_PATH_FUNC expands to a complete statement including the
> semicolon. Remove two extra trailing semicolons.
Wait a bit. The observation in the log message and the
implementation of GIT_PATH_FUNC() do not match.
#define GIT_PATH_FUNC(func, filename) \
const char *func(void) \
{ \
static char *ret; \
if (!ret) \
ret = git_pathdup(filename); \
return ret; \
}
The code generated does "include semicolon" but that is not why the
caller should place semicolon after the closing parens. Perhaps
replace "including the semicolon." with something else, like ", and
adding a semicolon after it not only is unnecessary but is wrong."
or soemthing like that?
It is a bit unfortunate that we need to live with a slight uglyness
of the resulting source code, unlike e.g. define_commit_slab() that
can (and must) end with a semicolon, which gives us a more natural
look. But that is a separate issue.
>
> Signed-off-by: Beat Bolli <dev+git@xxxxxxxxx>
> ---
> sequencer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 5354d4d51e..66e7073995 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -62,12 +62,12 @@ static GIT_PATH_FUNC(rebase_path_done, "rebase-merge/done")
> * The file to keep track of how many commands were already processed (e.g.
> * for the prompt).
> */
> -static GIT_PATH_FUNC(rebase_path_msgnum, "rebase-merge/msgnum");
> +static GIT_PATH_FUNC(rebase_path_msgnum, "rebase-merge/msgnum")
> /*
> * The file to keep track of how many commands are to be processed in total
> * (e.g. for the prompt).
> */
> -static GIT_PATH_FUNC(rebase_path_msgtotal, "rebase-merge/end");
> +static GIT_PATH_FUNC(rebase_path_msgtotal, "rebase-merge/end")
> /*
> * The commit message that is planned to be used for any changes that
> * need to be committed following a user interaction.
