[bug#67260] [PATCH emacs-team v11 0/7] You thought it was term/internal.el, but it was me, Dio!

[Suhail via Guix-patches via <guix-patches@gnu.org>]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> I finally came up with the perfectly cursed mix that enables us to
> actually load *and* graft our natively compiled packages with ease.

I can confirm that all the features being checked show up as natively
compiled as default - yay!

However, there seems to be some brittleness in whether or not
natively-compiled versions can be located.  Specifically, by reordering
the entries of the load-path, unloading previously loaded features, and
then reloading them some features will be reported as being
byte-compiled instead of natively-compiled.  Is my expectation that
reordering entries in the load-path shouldn't affect the
natively-compiled status misplaced?

From the previously shared test script, cases 01, 02, 03 pass now.
However, case
04-load-path-order-should-not-determine-natively-compiled-status still
fails.  Where in v10 it failed because 3 features previously reported as
being byte-compiled became natively-compiled, now it fails because the
same 3 features go from being natively-compiled to byte-compiled after
reordering load-path.  The features in question are the same ones that
were problematic in v10:

- term/internal
- mule-util
- ucs-normalize

My opinion: v11 seems to be an improvement over v10.  While I don't
believe that v11 is free of *all* bugs, I don't believe that that should
be a necessary pre-requisite before merging in.  I believe it would be
beneficial to merge v11 into emacs-team soon(ish) and for the emacs-team
branch to be merged into master soon thereafter.  A separate bug issue
can be created to track the peculiar dependence of the
native-compilation status on the ordering of entries in load-path.

Thoughts?

-- 
Suhail