Improve error handle-ability with Lua require

[LRitzdorf]

Normally, require uses Lua's pcall facility to catch any errors, increasing reliability if the user splits their config into modules. Any errors from within those modules are sent to the config manager for eventual display in the config-errors bar.

However, this use of pcall also catches the error case where the user tries to require a nonexistent module. This forcibly displays a message to the user, while also making it impossible to catch or detect such errors from within Lua itself (i.e. pcall(require, "nonexistent") always indicates success).

This PR makes require throw a proper error if module resolution fails, while still hiding (and adding to the config-errors list) any other errors that occur from inside the required module.

Would love feedback on a few details I'm not sure about:

• Currently, I detect module-resolution errors (as opposed to execution-time errors within the require'd module) just via string comparison, which feels kind of wrong. However, I don't think Lua gives us enough information to do this any other way — even the C return value from lua_pcall() is identical between the "nonexistent module" and "erroring module" cases (it's LUA_ERRRUN, specifically).
• Nested requires produce somewhat strange-looking error messages. I thiiiink this is probably okay, since it should still be clear where the error came from, but maybe we want to clean this up somehow?

Fixes #14534

---

Edit: This PR also makes Lua's original require available as __require, in case advanced users want to bypass Hyprland's error catching completely.

[github-actions]

Hello and thank you for making a PR to Hyprland!

Please check the PR Guidelines and make sure your PR follows them.
It will make the entire review process faster. :)

If your code can be tested, please always add tests. See more here.

beep boop, I'm just a bot. A real human will review your PR soon.

[LRitzdorf]

Just to clarify some behavior here:

• require("broken") has no change in behavior. It sends errors from within a broken module to the config manager's error list, and successfully returns an empty table.
• require("nonexistent") now throws an error. As with all other errors, this can be caught via pcall(), and if not it will stop execution of whatever Lua module contains it.
  • If this containing module was loaded via require as well, that require acts as in the "broken" case above.

[Dregu]

I'll try to remember to test this in a few hours with more notes, I've had several issues with safeLuaRequire, all of which are fixed by bypassing safeLuaRequire...

[Dregu]

Yep this fixed my own optional requires with pcall and also all issues with a few 3rd party modules that apparently use pcall(require), like lua-posix.

[LRitzdorf]

Yeah, this will still have nonstandard behavior in a few cases that might matter (i.e. ones where an existing but broken module is required). I wish there were a better way to handle this, like falling back to the standard Lua require for non-Hyprland Lua modules? But I don't think we can really detect what counts as a "Hyprland" module versus a system-provided one. AFAIK, we can't even ask Lua what path it found a given module at.

The alternative is to have some kind of additional input from the user — like a new safeRequire Lua command that calls safeLuaRequire(), or an optional protect = true argument to the existing require. But that means everyone has to update their configs to use it, which is maybe not ideal, so soon after the initial switch to Lua.

[Dregu]

I'd be happy enough if vanilla require was just renamed to __require so it's still available if needed.

[LRitzdorf]

I mean, I could add that to this PR very easily. But also, it'd only work for contexts where you can modify the Lua yourself, which doesn't include third-party modules like you mentioned above...

[Dregu]

Unless the first line in your config is require = __require, now everything uses vanilla require.

[vaxerski]

lgtm thanks