From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] refs: forbid clang to complain about unreachable code
Date: Fri, 10 Oct 2025 07:36:45 +0200 [thread overview]
Message-ID: <aOibbUqe-gfal6sd@pks.im> (raw)
In-Reply-To: <xmqqzf9zddia.fsf@gitster.g>
On Thu, Oct 09, 2025 at 01:30:21PM -0700, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > When `NO_SYMLINK_HEAD` is defined, `create_ref_symlink()` is hard-coded
> > as `(-1)`, and as a consequence the condition `!create_ref_symlink()`
> > always evaluates to false, rendering any code guarded by that condition
> > unreachable.
> >
> > Therefore, clang is _technically_ correct when it complains about
> > unreachable code. It does completely miss the fact that this is okay
> > because on _other_ platforms, where `NO_SYMLINK_HEAD` is not defined,
> > the code isn't unreachable at all.
> >
> > Let's use the same trick as in 82e79c63642c (git-compat-util: add
> > NOT_CONSTANT macro and use it in atfork_prepare(), 2025-03-17) to
> > appease clang while at the same time keeping the `-Wunreachable` flag
> > to potentially find _actually_ unreachable code.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > refs: forbid clang to complain about unreachable code
> >
> > Just upstreamin'
>
> It may not be a bad idea to deprecate core.preferSymlinkRefs now and
> remove it at Git 3.0 boundary. Some platforms may not be able to do
> symbolic links and use it to represent HEAD, but everybody should be
> able to create a small text file with a single line.
>
> But until then, this is a very reasonable thing to do.
Agreed. I don't see any reason why anyone would like to use symbolic
refs for this. The reading side for such symrefs may continue to exist
for a while. But the writing side can go away.
Patrick
next prev parent reply other threads:[~2025-10-10 5:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-09 7:46 [PATCH] refs: forbid clang to complain about unreachable code Johannes Schindelin via GitGitGadget
2025-10-09 20:30 ` Junio C Hamano
2025-10-10 5:36 ` Patrick Steinhardt [this message]
2025-10-10 5:34 ` Patrick Steinhardt
2025-10-10 13:49 ` Johannes Schindelin
2025-10-11 10:49 ` Patrick Steinhardt
2025-10-10 15:48 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aOibbUqe-gfal6sd@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.