[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finalizing 'inhibit-automatic-native-compilation'

From: Aymeric Agon-Rambosson
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Thu, 09 Feb 2023 08:26:09 +0100
User-agent: mu4e 1.6.10; emacs 28.1

Le mardi 7 février 2023 à 13:56, Andrea Corallo <akrl@sdf.org> a écrit :

Advising primitives is a dangerous action, it can lead the Emacs
machinery to malfunction anytime, these misbehaviors are not documented
and can change from version to version as from configuration to
configuration. The programmer who advises or redefines a primitive should be ready to understand the underlying machinery and work out
potential issues (as it was done in this case).

Agreed. Advising primitives was already frowned upon even before native compilation, it always was dangerous. However, tests have been doing this for quite some time.

I don't think this is a native comp specific problem, I'm sure one can
find similar examples also on non native comp enabled Emacses.

This is very possible, but in the cases I mentioned (projectile, yasnippet and beginend), the test failures or errors disappeared when we excluded the primitives from trampoline compilation. Sometimes, like in the projectile case, we were able to track exactly what happened, and offer a convincing explanation of the fix along with it. But that is not always the case : I have offered patches for yasnippet and beginend that solve test failures, and I can not completely justify them with anything other than "it solves the issue I'm presenting". On top of that, said issue has probably not been encountered by the upstream maintainer (maybe because they had the trampolines already available beforehand), we uncovered it with our specific build setting. Those patches may or may not be accepted by the upstream maintainers. My point being, the issues caused by widespread primitive advice in the test suites of addon packages, that we have just uncovered with trampoline compilation and our peculiar build environment, will probably be there for a long time. And I agree that this is the job of upstream maintainers to patch them, but they will be probably be very slow to fix them.

These examples were meant as an illustration of why we might want to exclude primitives from trampoline compilation in the (potentially quite long) meantime.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]