Make error messages consistent

[faze-geek]

Remove unnecessary lines to fix #673

[certik]

This change makes LPython return the correct message.

One thing that worries me is that this branch of the if statement structure in this function does not do anything after this change. Is that a good design of cast_helper?

It seems that cast_helper gives an error message right away if things cannot be cast. In which case, maybe we should just reformulate what this error message says. Instead of saying "not implemented", we should say "cannot cast c32 to string".

I do like the current error message (in this PR, as seen in the tests). Do we effectively have two places in LPython that return the error? In cast_helper and then later as well?

Should we just have one place, say cast_helper, that checks for errors, and then later we assume they are correct?

[czgdp1807]

Well IMO,

Is that a good design of cast_helper?

cast_helper is not abstract enough. Instead of a long if-else-if ladder I would prefer a simple rule map based with a tuple of type as keys and the desired cast as the value. Just pass in the types to the rule map and get your cast type. But anyways doesn't matter much now as its already implemented so let's keep using it.

Instead of saying "not implemented", we should say "cannot cast c32 to string".

Agreed. The second message is more transparent and helps in debugging.

Should we just have one place, say cast_helper, that checks for errors,

In an abstract sense, yes there should be only one place which checks for type compatibilities and return errors. If no errors then assume correctness in rest of your implementation.

[czgdp1807]

@faze-geek Why have you removed this SemanticError anyways?

[faze-geek]

The current SemanticError is inconsistent (as pointed in #673) so first I was changing the error inside the else itself . But then by --show-stacktrace I realised that by removing these lines , the type mismatch errors for 1. str + int, 2. str + float and 3. str + complex were getting generated from the same lines in the code ( which I thought is better than error generated from different lines)

[faze-geek]

I thought this would be straightforward ,I was unaware of cast_helper.

[Thirumalai-Shaktivel]

We get this message using the main:

$ lpython examples/expr2.py
semantic error: Type mismatch in binary operator; the types must be compatible
 --> examples/expr2.py:5:9
  |
5 |     s = "abc" + c
  |         ^^^^^   ^ type mismatch (str and c64)


Note: if any of the above error or warning messages are not clear or are lacking
context please report it to us (we consider that a bug that needs to be fixed).

I think this is fixed.
@czgdp1807