Ensure integer type constructor reject anything but numeric literals

[cburgdorf]

What was wrong?

Currently, our integer type constructor are too permissive. E.g. the following is allowed today even though it isn't guaranteed that val will fit into the u16)

    pub def bar(val: u8) -> u16:
        return u16(val)

I believe that our integer type constructor should simply not allow being used with anything other than a numeric literal such as 1 or -3.

Numeric literals can be checked on compile time whereas arbitrary variables can't.

How was it fixed?

• Added a function validate_is_numeric_literal and used it inside expr_call to validate
• Added a new error type NumericLiteralExpected
• Added a test to prove bad code is rejected.

Notice that this does not yet entail #145 but it is paving the way for it.

To-Do

• OPTIONAL: Update Spec if applicable

• Add entry to the release notes (may forgo for trivial changes)

• Clean up commit history

[codecov-io]

Codecov Report

Merging #163 (2a5648c) into master (00121f5) will decrease coverage by 0.09%.
The diff coverage is 55.55%.

@@            Coverage Diff             @@
##           master     #163      +/-   ##
==========================================
- Coverage   81.39%   81.29%   -0.10%     
==========================================
  Files          44       44              
  Lines        3133     3144      +11     
==========================================
+ Hits         2550     2556       +6     
- Misses        583      588       +5     

Impacted Files	Coverage Δ
semantics/src/errors.rs	5.26% <0.00%> (-0.30%)	⬇️
semantics/src/traversal/expressions.rs	75.97% <71.42%> (-0.19%)	⬇️
compiler/src/abi/elements.rs	73.23% <0.00%> (-0.68%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 00121f5...2a5648c. Read the comment docs.

[g-r-a-n-t]

Makes sense. We can perform compile time checks on literals like this and introduce methods like my_num.as_i128() for runtime casting.

[cburgdorf]

introduce methods like my_num.as_i128() for runtime casting.

Good idea. I'm writing up an issue for this. Eventually we might open up something like u32(x) in scenarios where x is <= 32 bit.

[cburgdorf]

I created an issue for the runtime conversions #165