Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 0 additions & 4 deletions src/lpython/semantics/python_ast_to_asr.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -950,10 +950,6 @@ class CommonVisitor : public AST::BaseVisitor<Derived> {
al, right->base.loc, right, ASR::cast_kindType::LogicalToInteger, int_type));
return ASR::down_cast<ASR::expr_t>(ASRUtils::make_Cast_t_value(
al, right->base.loc, right, ASR::cast_kindType::IntegerToComplex, left_type));
} else {
std::string rtype = ASRUtils::type_to_str_python(right_type);
throw SemanticError("Casting " + rtype + " to complex is not Implemented",
right->base.loc);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@faze-geek faze-geek Jun 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

}
}
if (!is_assign) { // This will only be used for BinOp
Expand Down
8 changes: 8 additions & 0 deletions tests/errors/test_str_mismatch.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
def main():
s : str
c : c32
c = 1+ 1j
s = "abc" + c
print(s)

main()
13 changes: 13 additions & 0 deletions tests/reference/asr-test_str_mismatch-4aad88f.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
{
"basename": "asr-test_str_mismatch-4aad88f",
"cmd": "lpython --show-asr --no-color {infile} -o {outfile}",
"infile": "tests/errors/test_str_mismatch.py",
"infile_hash": "cb0d79659e231dea35ff7fb9a0b3d61ea4e61a97a084dd4ef5897a74",
"outfile": null,
"outfile_hash": null,
"stdout": null,
"stdout_hash": null,
"stderr": "asr-test_str_mismatch-4aad88f.stderr",
"stderr_hash": "e64e38a8c35e63d2f542f67e1d133be318f46eac1f0e5aa1f187ca19",
"returncode": 2
}
5 changes: 5 additions & 0 deletions tests/reference/asr-test_str_mismatch-4aad88f.stderr
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
semantic error: Type mismatch in binary operator; the types must be compatible
--> tests/errors/test_str_mismatch.py:5:9
|
5 | s = "abc" + c
| ^^^^^ ^ type mismatch (str and c32)
Comment on lines +1 to +5
Copy link
Collaborator

@Thirumalai-Shaktivel Thirumalai-Shaktivel Nov 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

4 changes: 4 additions & 0 deletions tests/tests.toml
Original file line number Diff line number Diff line change
Expand Up @@ -575,3 +575,7 @@ tokens = true
[[test]]
filename = "errors/test_tuple1.py"
asr = true

[[test]]
filename = "errors/test_str_mismatch.py"
asr = true