The patch is certainly fine, though that just avoids a warning without any real effect. Have you tested in some way that the resulting package works well?

is that sthg that is supported upstream ? else it could bring trouble putting it into nixpkgs. I remember sthg about bit32 being embedded for 5.1 but a separate package for 5.2 etc.

@vcunat it should do, although I haven't checked. I'll do that shortly.

@teto you have it the wrong way around -- bit32 was added as a builtin module in Lua 5.2, and backported as a stand-alone module for 5.1.

I was mostly just being conservative in adding the isLuaJIT check to disabled originally, as I didn't want to diagnose the compile warning at that point (wanted to focus on moving the larger PR along). LuaJIT is ultimately API and ABI compatible with Lua 5.1, and as this stand-alone bit32 module is meant to target 5.1, it should work fine.

@vcunat I just did some very non-exhaustive testing (required the module, called some functions), seems to work fine with LuaJIT, as expected.

ok then. I don't think it should be patched unconditionnally though see my comment.

Hmm, disabled is completely removed, so the module makes sense on all versions, right? It's a bit messy, as 5.1 (and LuaJIT) didn't have builtin bit32 yet, 5.2 officially added it and 5.3 deprecated it. Moreover LuaJIT has bit which also exists as a library for other versions.

The generated package contains disabled = (luaOlder "5.1"); so it should be fine

We don't even have any lua older than 5.1 anymore.

@vcunat @teto Luarocks has some provision for tracking "builtin" modules, and it has bit32listed as a builtin for Lua 5.2 and 5.3, meaning it doesn't actually download/install the module for those Lua versions even if it is listed as a dependency.

We could maybe come up with some similar mechanism in nixpkgs, perhaps by universally removing bit32 from the inputs of Lua packages if they're being built for Lua >= 5.2?

@vcunat also please note, the semantics of LuaJIT's bit/BitOP module are not quite the same as PUC Lua's bit32, unfortunately, so they're not always interchangeable (FWIR some of the overflow behaviour is different).

Yes, I didn't mean to imply they're interchangeable.