feat: add the mayused modifier

[cnjhb]

Many of our macro-generated functions are never used. This causes the compiler to generate warnings. Functions decorated with the mayused attribute can eliminate these warnings.
I felt the original “attribute unused” was unintuitive, so I renamed it to mayused, meaning “maybe used.”
“attribute unused” always gives the impression that the function is completely unusable.
array.h also needs modification. If this PR gets merged, I'll make the changes then.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.48%. Comparing base (f1388f9) to head (617cd8e).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4057      +/-   ##
==========================================
+ Coverage   90.45%   90.48%   +0.02%     
==========================================
  Files         941      941              
  Lines       60390    60391       +1     
  Branches     1145     1145              
==========================================
+ Hits        54628    54644      +16     
+ Misses       5252     5241      -11     
+ Partials      510      506       -4     

Files with missing lines	Coverage Δ
common/luaclass.h	100.00% <ø> (ø)
common/util.h	77.77% <ø> (ø)

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Aire-One]

This causes the compiler to generate warnings.

How? I'm maybe missing something obvious here, but none of make recipes gave me this kind of output, and I don't recall seeing any in the Actions logs either.

I do agree that we probably have unused macro, tho. But I'm also unsure what are the drawback, if any, and how this new macro make things better. I may be lacking backgrounds on this (?)

[cnjhb]

This causes the compiler to generate warnings.

How? I'm maybe missing something obvious here, but none of make recipes gave me this kind of output, and I don't recall seeing any in the Actions logs either.

I do agree that we probably have unused macro, tho. But I'm also unsure what are the drawback, if any, and how this new macro make things better. I may be lacking backgrounds on this (?)

When I run make, I get this output:
/data/data/com.termux/files/home/Documents/awesome/build/common/luaclass.c:138:1: warning:
unused function ‘lua_class_property_array_remove’ [-Wunused-function]
Are you using Clang for compilation?

[Aire-One]

Are you using Clang for compilation?

I'm using GCC since that's what comes with the build-essential package and what we have in the CI. I've never really considered trying other compiler.

I can confirm the warnings are present now I'm trying clang and the PR does a good job at removing them. I'm still unsure how useful it is to remove these warning for macro generated code. I.e., "yes", not all structures generated from macro has a usage of every function from the macro 🤷. IMO, a more useful to test if generated function are used by at least one structure, so we can mark it as dead code that should be removed.

Quick note to open up the discussion: should we consider adding a workflow/matrix to test clang with our GitHub Actions workflow? I can see clang reveals some more additional warnings (I have not yet evaluated how useful they are).

[cnjhb]

Are you using Clang for compilation?

I'm using GCC since that's what comes with the build-essential package and what we have in the CI. I've never really considered trying other compiler.

I can confirm the warnings are present now I'm trying clang and the PR does a good job at removing them. I'm still unsure how useful it is to remove these warning for macro generated code. I.e., "yes", not all structures generated from macro has a usage of every function from the macro 🤷. IMO, a more useful to test if generated function are used by at least one structure, so we can mark it as dead code that should be removed.

Quick note to open up the discussion: should we consider adding a workflow/matrix to test clang with our GitHub Actions workflow? I can see clang reveals some more additional warnings (I have not yet evaluated how useful they are).

It might not be very useful after all. Clang isn't much better than GCC. As long as it ensures no warnings under the latest GCC, that's sufficient.

[Aire-One]

It might not be very useful after all. Clang isn't much better than GCC. As long as it ensures no warnings under the latest GCC, that's sufficient.

As said in #4060 (comment), maybe this can be part of a wider work to enforce coding rules on the project and raise the code quality.

[actionless]

i like the idea but the label not very clear, mb smth like ignore_unused_warning or ignore_unused would be more clear

[actionless]

see comment right above this

[cnjhb]

i like the idea but the label not very clear, mb smth like ignore_unused_warning or ignore_unused would be more clear

What do you think of the name maybe_unused? It’s a standard attribute introduced in C++17. I think it’s a better choice than ignore_unused.

[actionless]

sounds reasonable 😺👍

[actionless]

thanks!