Variables aren't detected as unused
Issue description:
The compiler doesn't detect variables as unused if they're read/written from an unused function.
new some_var;
stock GetVar()
return some_var;
main(){}
I think we should consider this a bug and not an intended behavior, because if the user didn't want any warnings about the variable being unused, they could just define it with the stock specifier (new stock some_var; or stock some_var;).
Minimal complete verifiable example (MCVE):
See above.
Workspace Information:
- Compiler version: 3.10.10, 3.2.3664
- Command line arguments provided (or sampctl version):
- Operating System:
Special thanks to user DeimoS from the pro-pawn.ru forums who originally discovered this bug.
That's a tricky one. Yes, it should be stock, but it's almost pointing at the wrong place for the mistake. Anyone getting the warning now is likely to look through the code and see this as a bug in the compiler - because it clearly IS used in their code, you can literally point at the place it is used. The problem is that the place it is used is itself not used, and so the mistake propagates up until you get a warning on the wrong thing. I'm not really sure what the correct solution for this is.
Perhaps, we could create a new usage flag (say, uREFUNUSED) and mark global variables with that flag instead of uREAD and uWRITTEN when they are referenced from an unused function? This would allow the compiler to both throw such variables away from the binary file (which could be especially effective against huge unused arrays) and avoid annoying the user with useless warnings.
Possibly, but then you get the opposite problem - people not getting data compiled that they expect to be compiled, and no warning for a variable without stock that isn't used. I'm thinking about some new warning, or a change of wording to the existing warning. Instead of "variable is never used", something like "variable is never used in reachable code". That makes it clear that, while you might have thought you were using the variable, the place you used it isn't itself used.
Possibly, but then you get the opposite problem - people not getting data compiled that they expect to be compiled
Not sure what you mean by that exactly. If the data isn't used - it's not needed, so it shouldn't really matter if it's present in the binary file or not. Am I wrong?
and no warning for a variable without stock that isn't used.
That's how the compiler currently works, that won't change.
I'm thinking about some new warning, or a change of wording to the existing warning. Instead of "variable is never used", something like "variable is never used in reachable code".
Something tells me such warnings may really annoy the user, especially on big gamemode scripts with lots of unused functions and variables.
Unless we make this warning disabled by default, maybe? Recently DeimoS (they don't have a GitHub account, so I guess I'll have to mention them this way) suggested me to add a few new warnings, but make them disabled by default and toggleable via #pragma warning (so they won't annoy the user if they don't need them), and also reserve a separate range of IDs for them starting from, say, 300 (so the warning you suggest would be something like warning 300: variable is only used in unused code (symbol "%s")).
I don't really remember all of the warnings DeimoS suggested, but if you like this idea in general, I may search the chat logs to find them.
Not sure what you mean by that exactly. If the data isn't used - it's not needed, so it shouldn't really matter if it's present in the binary file or not. Am I wrong?
I mean, they may declare a variable expecting it to be used, and then wonder why it isn't.
That's how the compiler currently works, that won't change.
Oh, so it is. In that case carry on.
What about the idea of disabled-by-default warnings that I described in my previous post? Would you approve it?
I like it (though it's not solely up to me). Some sort of -Wall flag. You mentioned using #pragma to enable them, but a flag to turn them all on would be good too.
This issue has been automatically marked as stale because it has not had recent activity.