I’m pretty sure it works, FWIW. As in, I read the whole (wonderful) investigation by @tnytown, tried a bunch of less hacky things, and they all reproduced the original bug with both the old and new LLVM, but this keeps it fixed under LLVM 14 and keeps it fixed under the new LLVM. (I believe @Atemu no longer uses macOS.)

But certainly it would be good for someone who actually uses emacs-macport to take this for a little spin.

No idea why I did it the more complicated way, this looks more reasonable!

Most probably something like "compiler said X, so let's fix it" and "use #define guards to not break on Linux" iterated six times?

But I digress.

Maybe this file should be sent to Mitsuharu-san?

It was the result of a long investigation in #127902 (comment) and #127902 (comment). I believe that the emacs-macport code is semantically incorrect but that a commit that is reverted in Apple’s Clang but not the vanilla one we use, that takes advantage of the incorrect annotations, means that it doesn’t break when compiled with the Xcode toolchain. So the correct upstream fix would involve fixing C memory management type issues. It being reported upstream would be good, but I think not a blocker for this fix (which is required to drop EOL LLVMs), and I don’t think the hack is upstreamable.

This is not my area but I trust @emilazy. So please merge this as you see fit @emilazy :)

@emilazy I'm getting this, when trying to build this:

Running phase: configurePhase
@nix { "action": "setPhase", "phase": "configurePhase" }
patching script interpreter paths in ./configure
./configure: interpreter directive changed from "#! /bin/sh" to "/nix/store/3g3sgwpnig8sd0w9wbs7d5gy512r43cq-bash-5.3p3/bin/sh"
configure flags: --prefix=/nix/store/h3raf67dr2w6xs698nkfkwr97yra9sx8-emacs-mac-macport-30.2.50 --disable-build-details --with-modules --without-gif --without-jpeg --without-png --without-tiff --witho>
checking for xcrun... xcrun
checking for make... yes
checking for GNU Make... make
checking build system type... aarch64-apple-darwin24.6.0
checking host system type... aarch64-apple-darwin24.6.0
checking whether the C compiler works... no
configure: error: in '/nix/var/nix/builds/nix-build-emacs-mac-macport-30.2.50.drv-3/source':
configure: error: C compiler cannot create executables
See 'config.log' for more details

Hmm, I’m not getting that exact failure, but #437637 did regress the build. I’ve pushed a fix for that.

My test build passed. @kfiz, could you try it again and let me know exactly how you were testing?

I’ll let @jian-lin have another look given the new commit too.

Incidentally, I see that nobody has reported that emacs-macport currently fails to build on nixpkgs-unstable after 5 days. I’m wondering how popular the package is at this point.

My test build passed. @kfiz, could you try it again and let me know exactly how you were testing?

I’ll let @jian-lin have another look given the new commit too.

@emilazy works for me now.

Incidentally, I see that nobody has reported that emacs-macport currently fails to build on nixpkgs-unstable after 5 days. I’m wondering how popular the package is at this point.

@emilazy my strong assumption is that most of the emacs-macport users have temporarily switched to vanilla emacs to have a functional emacs v30 version. They will switch back if there is a v30 for emacs-macport.

Thanks for the reviews :)

Maybe we should check whether @juuyokka is still interested in working on #393512, as it seems like the emacs-macport package may become a maintenance burden if it stays on an old version indefinitely.

Maybe we should check whether @juuyokka is still interested in working on #393512, as it seems like the emacs-macport package may become a maintenance burden if it stays on an old version indefinitely.

@emilazy agree. I think in the meantime we should switch to the fork that is already mentioned there https://github.com/jdtsmith/emacs-mac until it is clear what happens to the original package. I've been test driving it and it seems quite stable to me. I can send a new PR that is based on #393512.