Is it really a "bug"?
I don't understand the interest of those parentheses surrounding the declared names (given the way the LUA_API macro is declared and used, and the fact that the return type itself is not surrounded by parentheses; and the fact that LUA_API does not allows reordering, for example to insert meta-attributes for the declared name AFTER the return type and NOT affecting the return type itself; for now LUA_API assumes that attributes such as "external cdecl" do not apply to the return type and implicitly apply to the declared name, but I'm not sure that this is even true if the name is "decorated" by surrounding parentheses).
Is it just for "readability"? IMHO it just adds an unneeded layer of obscurity (it could as well create a syntaxic problem where part of the return type could be used as the declared name, and the function name would be considered as part of a function call in a complex type declaration such as declaring a function returning a function type)....
I would have preferred that the LUA_API macro was taking parameters instead of being parameterless:
#define LUA_API(return_type, function_name, parameters in parentheses) /* ... */
allowing also the placement of declaration attributes between the return type and the declared name, or between the function name and parameters in parentheses, or after the parentheses. For now it assumes that attributes are decorated using a GCC style, using `declspec(...)` , or implicitly apply to the declaration without any "decoration", such as MSC styles like
`cdecl` or `__cdecl`, or standard C++ style like
`extern "C"` but that can be used only at start of the declaration (things get more complicate when a single declaration statement is used to group several declarators with the same return type, and not all declarators are for functions, but could be used for declaring other types or variables in a comma-separated list: this is not the case in lua.h, but the C syntax allows it, and placing the attributes only at start of the statement means that they would apply to all declarators in the list and in some cases the C compiler will not be able to discriminate their applicability).
There are other attributes possible which have more precise placement requirements (such as within square brackets) to provide other semantics for each part (return type, call type and visibily/scope, execution, addition of implicit/synthetic parameters, isolation, or semantic attributes used by optimizers or linters or code generators, or debugging features and possible reflection/RTTI at runtime...) of the full declaration. Those extra attributes can be useful, including for debugging changes in the code and automating the creation of coverage tests, or generating a documentation directly and instantly usable in IDEs, that would allow faster and easier detection of bugs.
As well the `function_name` may need to be adjusted (e.g. by concatenating some prefix or suffix for scoping them with something else than the "lua_" prefix explicity given); but note that luaconf.h uses various prefixes "LUA_", "L_, "LUAI_", "l_", "lua_", "luai_"... and this does not easily scope the API without lot of manual patching everywhere else in all source files.
The fact that `luaL_addgsub` was not using this extra pairs of parentheses just proves that they were not needed for every other function.
