Support -Werror for GCC compatability

[chuggafan]

https://github.com/LADSoft/OrangeC/commit/5e8957686d0cef25b42b001c9c38f9be71bebb30#r53142153

Discussion kicks off from here.

The idea for how to implement a similar system to how gcc and clang do error options, we could implement a similar -Wall -Wextra -Weverything that clang has as well giving control over experimental, guaranteed, and other options, but that's for the future.

Idea for how to do this: Go to the recently added errors file, add another parameter for the name of the error, set the name + number into a static const unordered_map (since our goal is finding, this should be fine, hopefully), and then use the existing "mark warnings as errors" functionality to set warnings as errors.

[LADSoft]

we could do it in stages - the most obvious errors first and then hone in from there...

[chuggafan]

The question is: will we have GCC compat for certain error names? And if so, what errors are they?

[chuggafan]

Doing this while doing #610 because they're related and I think I'll use the same strategies to accomplish it. Just adding 4 macros to errorlist.h and just making it so that there's help and the GCC-compat names.

[GitMensch]

Thanks @chuggafan - is there already a PR for both issues or something that you (currently/later?) work on?

[chuggafan]

I'm currently working on it, there actually aren't as many shared warnings as I thought however...

[GitMensch]

I'm currently working on it

cool!

there actually aren't as many shared warnings as I thought however...

Hm, is this because occ does not warn the stuff GCC does or because of one of those compilers combines the warnings under a single flag while the other doesn't?

In the first case it seems reasonable to create FRs for the "most reasonable warnings" missing, in the second case occ could get a new warning "group" to match the one from GCC.

[chuggafan]

Hm, is this because occ does not warn the stuff GCC does or because of one of those compilers combines the warnings under a single flag while the other doesn't?

A lot of the former, 1-2 of the latter.

A lot of it has to do with static analysis that would really slow down builds but are useful to implement for future ability to verify say, that malloc and dealloc happen.

[GitMensch]

Checking the state with the last release (February 2023):

• occ --help lists /wx /werror
• compiling with occ -wx seems to have the expected effect
• compiling with both occ -Werror and occ -werror raises a diagnostic "Warning: does not pertain to any warning or error" (without an actual reference)

[LADSoft]

so occ -werror should have been documented differently based on how the code works. Also there were a number of bugs in the code so it didn't actually work as intended. I've fixed all this but on the 'symtab' branch. Speaking of which I'm very close on moving that to master... to combat compiler slowdowns of the compiled code from using so many iterators the way we are now I've been having to update how the inline functions are done, should be done with that in the near future...