Allow more expressions to be used in array sizes

[jfecher]

Related issue(s)

Resolves #415

Description

Summary of changes

Allows use of global variables and simple arithmetic expressions in addition to integer literals within array-size expressions.

Previously an array with repeated-elements like the following: [0; 42] required an integer literal like 42 for the
count of repeated elements. This PR expands this a bit such that it may include global integer variables, and simple
operations on them: +, -, *, /, %, &, |, ^, and !.

This is done by adding a mini-evaluator during name resolution which is not ideal. Ideally, we could allow any comptime Field expression by delaying this until ssa and relying on the inlining done in that pass to remove all function calls, comptime variable references, and fold all arithmetic. For now though, this PR brings us most of the way there.

Test additions / changes

Adds a quick addition to the globals test.

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.

[kevaundray]

So in the future, ideally, we will need to refactor this code out and move it to the ssa?

[jfecher]

If we want to allow for all comptime expressions, yes. Either that or it can be done with terra's scheme of a wrapper language I mentioned before

[kevaundray]

Alright, if we merge , can you open up another issue to support all comptime expressions, referencing this PR?

[jfecher]

Made #445

[guipublic]

SSA is already folding arithmetic expressions so there is not need to add the mini-evaluator to the SSA pass.
For now, we need to know the array size because of the monomorphisation which is done before SSA.
If we want in future to use the SSA folding for this, that mean we need somehow to support arrays with unknown size until we get there. I wonder how difficult that would be.

[jfecher]

Agreed @guipublic. Those difficulties were ultimately why I ended up with this less flexible approach instead.

[guipublic]

I think the mini-evaluator is simple enough so that it won't have nor cause any big issue, yet it already brings a lot of flexibility for the user