Feature/char type

[gluax]

Implements the basic char type in Leo.
Closes #939.
Closes #940.
Closes #942.
Closes #946.
Closes #950.

What it does is allow the base type into language.
Adds Parser Tests for the char type.
Adds Compiler Tests for the char type. Should I merge in the compiler tests branch first and have that branch dep on this one? Then we can merge this branch to master after that one is in, or we can merge this one into that branch.
The ASG passes both the character and the field version to the compiler. This is so the character can be printed, and the compiler uses the field portion for everything else.

The follow is allowed in Leo and those are also allowed in input files.

let a = 'a';
let b = '\t';
let c: char = '\u{2764}';
let d = '\u{00306E}';
let e = '❤️';
let f = 'の';
let g = '\x2A';
let h = '\x09';

Output files lose the single quotes on the char; should I force it to put them there? Or should I have them write the field to the output instead? Example of current behavior:

r: char = a;

Note: Operators are not yet implemented.

[codecov]

Codecov Report

Merging #957 (bdcd945) into master (7aa3fa3) will increase coverage by 0.38%.
The diff coverage is 78.06%.

@@            Coverage Diff             @@
##           master     #957      +/-   ##
==========================================
+ Coverage   74.97%   75.35%   +0.38%     
==========================================
  Files         429      435       +6     
  Lines       17170    17565     +395     
==========================================
+ Hits        12873    13236     +363     
- Misses       4297     4329      +32     

Impacted Files	Coverage Δ
asg/src/error/mod.rs	54.19% <ø> (ø)
ast/src/errors/reducer.rs	5.55% <0.00%> (-1.59%)	⬇️
compiler/src/errors/expression.rs	2.22% <0.00%> (-0.06%)	⬇️
compiler/src/errors/function.rs	23.43% <0.00%> (-0.76%)	⬇️
compiler/src/errors/value/char.rs	0.00% <0.00%> (ø)
compiler/src/value/mod.rs	100.00% <ø> (ø)
input/src/errors/parser.rs	26.53% <0.00%> (-3.71%)	⬇️
input/src/expressions/expression.rs	6.06% <0.00%> (-0.61%)	⬇️
input/src/values/value.rs	14.28% <0.00%> (-1.72%)	⬇️
parser/src/tokenizer/mod.rs	97.50% <ø> (+12.31%)	⬆️
... and 52 more

---

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 7aa3fa3...bdcd945. Read the comment docs.

[acoglio]

I vote for putting single quotes (e.g. 'a') in output files, for greater clarity and syntactic uniformity.

Regarding support for

let g = '\xH2A';
let h = '\xH9';
let i = '\xO011';
let j = '\xO172';

actually the RFC (https://github.com/AleoHQ/leo/blob/master/docs/rfc/001-initial-strings.md#characters), and the ABNF PR (#954), only allow

let a = '\x0a';
let b = '\x7E';
let c = '\x44';
...

that is \x followed by an octal digit followed by a hex digit. The rationale was to follow Rust (https://doc.rust-lang.org/stable/reference/tokens.html#ascii-escapes) and to have something simple. So we need to change either the implementation, or the RFC and ABNF PR to make things consistent one way or the other.

[gluax]

Ah, I totally misread how that worked, @acoglio. Whoops. Either way, I don't mind changing the code to match the RFC to match rust. We could also change the RFC, but I'm more in favor of matching rust's behavior.

[acoglio]

I'm also in favor of matching Rust's behavior -- thanks.

[gluax]

Output changes now write chars as 'a'.
Hex variables have been changed.

Using #920 for tests. Though current tests that should pass currently fail till snarkVM has support for field equality.
Need to add more purposely failed test first, wanna see what I'm missing from codecov first.

[gluax]

I started on #946. This is possible bc even though field eq ops are not implemented yet, the function body still lives. The char type calls these existing templates on the field type. Thus when those are implanted the char ones will just succeed.

[acoglio]

Looks good.

[damirka]

Overall good!

One note. Should we have consistency in naming of Tokens? We have CharLit and AddressLit tokens but string is StringLiteral. I can submit a quick patch.

UPD: done.

[damirka]

Found two issues:

1. We can define multiple symbols within one char, it's going to take only first one. Should we keep it or error out?

let b: char = 'abcdefg';
let c: char = '\u{bbbbb}\u{aaaa}'; // works only with unicode escapes
let d: char = '😭😂😘';

2. For some reason strings with emojis fail on getting subtendril:

let s = "😒";

// thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ValidationFailed',
// 5: leo_parser::tokenizer::lexer::<impl leo_parser::tokenizer::token::Token>::eat
//             at ./parser/src/tokenizer/lexer.rs:227:29

[gluax]

@damirka #1 shouldn't be allowed but should be an easy fix; I definitely just messed that up when I changed the char parsing style.

#2 I believe it is probably an issue since a Unicode symbol is many u8 bytes, and since it's not an escape, I probably attempted to send over one byte over at a time. At least that's my guess.

I'll look into these as well and see what we can get fixed.

[gluax]

#1 has been resolved.
#2 was resolved by @damirka and me through some pair programming! Though it only supports up to 4 bytes. Meaning emojis similar to🤷🏿‍♀️ will not work. This is because the first byte of a Unicode specifies the length but in this case, this has more than 4 bytes. Not sure how to resolve that. Rust also fails to print this as one character and instead prints three. This is what Leo does as well now.

[damirka]

LGTM
Tested multiple scenarios, and it looks like we got it working.