Straight.el: throw/catch for bytecode detection does not work on nativecomp branch

[aaronjensen]

What's wrong

I've been trying out the nativecomp branch and I use straight.el as my package manager. It's very possible this is an Emacs bug, but when reporting it to emacs-devel they suggested I report it here to try and narrow it down.

One of the things that it does is throw when it detects that its own compiled bytecode has changed. It does this from within straight.el:

https://github.com/raxod502/straight.el/blob/2d407bccd9378f1d5218f8ba2ae85c6be73fbaf1/straight.el#L45-L49

It then catches within bootstrap.el, which loads straight.el:

https://github.com/raxod502/straight.el/blob/2d407bccd9378f1d5218f8ba2ae85c6be73fbaf1/bootstrap.el#L47-L54

Unfortunately, this doesn't work with nativecomp. It claims that there's no matching catch when a throw actually happens.

Warning (initialization): An error occurred while loading
‘/Users/aaronjensen/.emacs.d/early-init.el’:

No catch for tag: emacs-version-changed, nil

Directions to reproduce

Build emacs with nativecomp. Run Emacs with an init.el containing just the bootstrap code. Watch the async compilation and wait for it to at least compile straight.el. Once that's done, rebuild emacs (you can just touch xdisp.c) and run emacs again.

Version information

• Emacs version: 28.0.50 nativecomp
• Operating system: macOS

[aaronjensen]

After a little more digging, I believe the problem is:

https://github.com/raxod502/straight.el/blob/2d407bccd9378f1d5218f8ba2ae85c6be73fbaf1/bootstrap.el#L62-L65

With nativecomp, loading the elc will load the eln. Only the elc was recompiled, not the eln, so the old eln also throws, but there's no catch.

I have a thread on emacs-devel discussing this. I'll report back with what their suggestion is.

[progfolio]

Thank you for the report.
I suspect this is related: https://github.com/raxod502/straight.el/issues/643

With nativecomp, loading the elc will load the eln. Only the elc was recompiled, not the eln, so the old eln also throws, but there's no catch.

This sounds like the root of the problem.
Can you confirm that deleting the eln file before launching Emacs works around this error?

[aaronjensen]

Yes, that’s how I work around it.

[aaronjensen]

It does sound like the eln should be invalidated, so I will open an issue on emacs.

[aaronjensen]

Filed upstream: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46617

[aaronjensen]

It does not appear that this will be fixed in a way that requires no changes to straight.el.

Straight will have to become aware of native compilation and either do the native compilation itself, or delete the corresponding eln any time it does a byte compiling of straight.el.

• Loading an elc explicitly will no longer load the eln implicitly, which ultimately should "fix" this issue at the cost of straight.el not being loaded native, ever
• There is now a function to locate the eln: comp-lookup-eln which could be used to force loading the eln

It might make sense to update bootstrap to, when the version check fails:

1. Delete the corresponding eln, if it exists and native-comp is enabled
2. Byte compile
3. Load straight.el without an extension, allowing Emacs to pick the best file to load and triggering an async native compilation of straight.el

Alternatively, you could byte compile, then native compile, then load the native compiled version explicitly.

[progfolio]

Thanks for the analysis, Aaron. If you're willing to submit a pull implementing any of the above, we'd gladly work with you on it.
Otherwise, I will get to this issue eventually, but I have it marked as a lower priority in my notes because I'm not personally on the nativecomp branch and I'd prefer to let the dust settle on that feature rather than chasing an evolving API.

[progfolio]

Closing due to #729