Add COMPILER_OPT_SETTING and fix related env vars

[NotsoanoNimus]

Looks like the CompileOptLevel struct was a tad misleading. The values did not represent O0 through 03 as they claimed to. This is proven by walking along -O0 to -O5 on master with (obv. comment out the second line if not on this branch):

fn void main()
{
	$echo @sprintf("Compiler opt level: %s", env::COMPILER_OPT_LEVEL);
	$echo @sprintf("Compiler opt setting: %s", env::COMPILER_OPT_SETTING);
}

Also added the COMPILER_OPT_SETTING to explicitly reference return the currently-set optimization settings given in the help info. This is important if you have features that are switching on/off at compile-time based on this information.

For example, I have some asserts that I will just return out of on optimized/release builds, and the COMPILER_OPT_LEVEL wasn't enough for me. Perhaps not conventional, but it's a use-case nonetheless.

Above code after changes:

> for x in 0 1 2 3 4 5 s z; do echo ">>> LEVEL 'O$x':";./build/c3c -O$x compile-run somemain.c3 2>/dev/null | grep 'Compiler' && echo "========"; done
>>> LEVEL 'O0':
c3c: Compiler opt level: NONE
c3c: Compiler opt setting: O0
========
>>> LEVEL 'O1':
c3c: Compiler opt level: MORE
c3c: Compiler opt setting: O1
========
>>> LEVEL 'O2':
c3c: Compiler opt level: MORE
c3c: Compiler opt setting: O2
========
>>> LEVEL 'O3':
c3c: Compiler opt level: MORE
c3c: Compiler opt setting: O3
========
>>> LEVEL 'O4':
c3c: Compiler opt level: AGGRESSIVE
c3c: Compiler opt setting: O4
========
>>> LEVEL 'O5':
c3c: Compiler opt level: AGGRESSIVE
c3c: Compiler opt setting: O5
========
>>> LEVEL 'Os':
c3c: Compiler opt level: MORE
c3c: Compiler opt setting: SMALL
========
>>> LEVEL 'Oz':
c3c: Compiler opt level: MORE
c3c: Compiler opt setting: TINY
========

[lerno]

This is all intentional. The frontend -O0 -> -O5 are "packages" of settings.

[NotsoanoNimus]

I see. The intention here was to explicitly allow behavior to change at compile-time with the current -Ox setting specifically.

Running the following on master is still confusing nonetheless.

fn void main()
{
	$echo @sprintf("Compiler opt level: %s", env::COMPILER_OPT_LEVEL);
}

> for x in 0 1 2 3 4 5 s z; do echo ">>> LEVEL 'O$x':";./build/c3c -O$x compile-run somemain.c3 2>/dev/null | grep 'Compiler' && echo "========"; done
>>> LEVEL 'O0':
c3c: Compiler opt level: O0
========
>>> LEVEL 'O1':
c3c: Compiler opt level: O2
========
>>> LEVEL 'O2':
c3c: Compiler opt level: O2
========
>>> LEVEL 'O3':
c3c: Compiler opt level: O2
========
>>> LEVEL 'O4':
c3c: Compiler opt level: O3
========
>>> LEVEL 'O5':
c3c: Compiler opt level: O3
========
>>> LEVEL 'Os':
c3c: Compiler opt level: O2
========
>>> LEVEL 'Oz':
c3c: Compiler opt level: O2
========

[lerno]

Yes, but this is a misunderstanding of what the -Ox settings are for. They are packages of optimization. Other languages don't even allow that much granularity, see Zig for example. Even in Clang, this is how they actually do work. What matters is whether the intent is to optimize or not, not whether the basic flag is -O0 or -O1. Because we may pick -O3 and then reset the optimization level to "none" for example just to get the other changes due to -O3

[NotsoanoNimus]

Fair point, I see what you mean now.

I think, rather than basing stuff off of the optimization level -- because as you said, what's done in each is arbitrary and not pinned to anything -- it might be helpful to at least have $feature tests for whether PANIC / ASSERT / etc. are currently enabled or optimized out.

Do you think that might be of any value? (or does something like this already exist?)

[lerno]

More such constants would be useful yes.

[lerno]

Since this one is for the -Ox frontend arguments, I'll close it then. Other additions can have their own PR, ok?