feat: support more types in switch statements

[mattjohnsonpint]

Fixes#2919
Fixes#648

Changes proposed in this pull request:

• Fixes compiler error when using a switch statement with certain types.
  • All numeric types that were already supported
  • Add support for strings, floats, and 64-bit ints
• Adds tests to validate

I've reused the existing equality comparison logic, so any behavior for == is retained for switch cases, including overloads, etc.

• I've read the contributing guidelines
• I've added my name and email to the NOTICE file

[HerrCai0907]

as does not use string pool..so it is impossible to compare two string directly with ptr. string.eq must be used for each check.

[mattjohnsonpint]

as does not use string pool..so it is impossible to compare two string directly with ptr. string.eq must be used for each check.

... oh. I see. I was thrown off because the naive test passed, but this one fails:

assert(doSwitchString("o"+"n"+"e")==1);

because the concatenated resulting string is in a different variable and thus a different pointer than the "one" in the switch case.

I'll add a special case for strings. I think it should be good for the rest though.

[CountBleck]

I wonder if this should just be using the == operator overload for all objects that have them...

[mattjohnsonpint]

Working on a revision. I think I can reuse some existing code.

I found that string equality isn't handled by the TypeKind.String case of makeEq, but rather by the __eq function that's implemented as an operator overload for == on the String class.

Much of the logic to determine whether to call makeEq or invoke an overload is already present in compileCommutativeCompareBinaryExpression, but I need to split left from right to do this correctly in a switch statement, since the "left" is compiled once and shared across switch cases.

[mattjohnsonpint]

This is now updated with the revisions. I've split the existing compileCommutativeCompareBinaryExpression method such that the core logic can be re-used when evaluating the switch cases. I've also added more tests to show that it works as expected. Thanks.

[mattjohnsonpint]

@HerrCai0907 any other adjustments you would like?

[HerrCai0907]

LGTM.

[CountBleck]

LGTM. And wow, these method names (compileCommutativeCompareBinaryExpressionFromParts) are starting to get longer and longer 😛