Error Message (Dict,Set,List ) Type Mismatch

[assem2002]

Fixes #2042

The Fix

Screen Shot Of The Code In The Issue Description After Fix.

The issue we're facing could be described as "CONSTRUCTION WHILE ASSIGNING" problem. It happens when _visitassign function is invoked. It could happen with annassign function also as shown below

Mention To Some Other Cases

The issue appears in the following code:

someVar : list[i32]
someVar = {1 ,"whatever"}

And also here:

@dataclass
class FullFormValue:
    list_i32 : list[i32]
    string   : str

ttype    : str = FullFormValue(DEAD_LIST, 1)
contents : FullFormValue = FullFormValue([1, 2], '')

• The first code and its other forms (set,dict,list) are handled by the fix.
• The Second code is handling with data class construction, which the fix doesn't provide the same debug message for. but data classes are constructed and get bound to a variable in the same line of code, so it would be easy to see the whole mismatch mess you've made.

**Let me know if the object construction handling is a concern and needs to be debugged in some other way.

Simplifying the code

• We could write the type check code as a function under ASRUtiles namespace, as it's redundant piece of code here.

• I don't have deep grasp on the visit_assign function so I didn't mess with its flow because - as I think - there's type coercion happening.

• I just added a piece of code to solve the problem, but I think the redundancy of the code we face could be handled easily by doing early type check and remove the latter one.

[kmr-srbh]

Please replace "Fix Issue #2042" with "Fixes #2042" so that the PR gets linked to the issue.

[assem2002]

I Edited it, #Thanks @kmr-srbh

[Thirumalai-Shaktivel]

Please mark this PR ready for review once it is ready.

[assem2002]

@Thirumalai-Shaktivel

The problem we face in issue #2042 appears to be more complex.

@Shaikh-Ubaid suggested an error recovery mechanism to be implemented in the system to handle such multiple errors while doing ASR construction.

Probably we should make a bigger issue with specified tasks as long as there's no such mechanism or similar ones already implemented.

I'll draft the PR,but I think the issue should be closed unless a hard-coded fix is fine for now.

[Shaikh-Ubaid]

The fix in this PR doesn't seem to be a high priority. I think we should fix it issue by adding support for error-recovery (as mentioned in https://github.com/lcompilers/lpython/issues/2042#issuecomment-1981703862), which in itself is a larger issue. Should we tackle this later @certik?

[certik]

Yes, correct. We have to extend the ASR->ASR transformation to just report all errors and recover from them. We should not be catching exceptions like that. In fact ideally we should not use exceptions at all. I think we should be able to recover on the level of statements, and then have special handling in blocks of statements (functions).

In terms of priorities, first we should deliver beta quality ASR and LLVM (via LFortran) for compiling valid code. Only then focus on beautiful error messages for invalid code.