confusing error message when attempting to append to list #166

Closed
opened 2022-01-13 21:26:27 +08:00 by sb10q · 8 comments
Owner

It's pretty guaranteed that users will try to append to lists:

def run() -> int32:
    data = []
    data.append(3)
    return 0

Unfortunately the error message is pretty bad:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Cannot unify record[append=var7] with list[var6] at classes.py: line 3 column 5"', nac3standalone/src/main.rs:224:35

Side note: Can we get rid of those "varXX" references in error messages once and for all? I don't think it's a good idea to ever print that.

It's pretty guaranteed that users will try to append to lists: ```python def run() -> int32: data = [] data.append(3) return 0 ``` Unfortunately the error message is pretty bad: ``` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Cannot unify record[append=var7] with list[var6] at classes.py: line 3 column 5"', nac3standalone/src/main.rs:224:35 ``` Side note: Can we get rid of those "varXX" references in error messages once and for all? I don't think it's a good idea to ever print that.
Author
Owner

The message is better now, but non-deterministic.

Sometimes I get:

`list[var56]::append` field does not exist at /home/sb/nac3/nac3artiq/demo/demo.py: line 15 column 9

and sometimes:

list[var60]::append` field does not exist at /home/sb/nac3/nac3artiq/demo/demo.py: line 15 column 9

What about removing [varXX] completely? It brings nothing to the user and just makes the error more confusing.

We probably also want to say "field or method" and not just "field".

The Python notation for attributes is also . and not ::. Using the former would make the message clearer.

The message is better now, but non-deterministic. Sometimes I get: ``` `list[var56]::append` field does not exist at /home/sb/nac3/nac3artiq/demo/demo.py: line 15 column 9 ``` and sometimes: ``` list[var60]::append` field does not exist at /home/sb/nac3/nac3artiq/demo/demo.py: line 15 column 9 ``` What about removing ``[varXX]`` completely? It brings nothing to the user and just makes the error more confusing. We probably also want to say "field or method" and not just "field". The Python notation for attributes is also ``.`` and not ``::``. Using the former would make the message clearer.
Contributor

We could remove the type variable, but in general the type variable would be useful for diagnostics for other cases. Making the type variable name deterministic is hard because the execution order is indeterministic and we have to rely on something to name it.

We could remove the type variable, but in general the type variable would be useful for diagnostics for other cases. Making the type variable name deterministic is hard because the execution order is indeterministic and we have to rely on something to name it.
Author
Owner

Maybe make it optional? It then could be enabled with an environment variable that nac3artiq reads. Similar to ARTIQ_DUMP_LLVM etc. in the legacy compiler.

Maybe make it optional? It then could be enabled with an environment variable that nac3artiq reads. Similar to ARTIQ_DUMP_LLVM etc. in the legacy compiler.
Author
Owner

Assuming by "diagnostics" you mean "figuring out compiler bugs".

Assuming by "diagnostics" you mean "figuring out compiler bugs".
Contributor

Maybe make it optional? It then could be enabled with an environment variable that nac3artiq reads. Similar to ARTIQ_DUMP_LLVM etc. in the legacy compiler.

Well the problem is that, it may be helpful to print something like list[int32], but for more complicated types that have several generic parameters with some type variables, we will have to print the type variable in some way... Or we could just omit the generic parameters in the default case.

> Maybe make it optional? It then could be enabled with an environment variable that nac3artiq reads. Similar to ARTIQ_DUMP_LLVM etc. in the legacy compiler. Well the problem is that, it may be helpful to print something like `list[int32]`, but for more complicated types that have several generic parameters with some type variables, we will have to print the type variable in some way... Or we could just omit the generic parameters in the default case.
Contributor

Assuming by "diagnostics" you mean "figuring out compiler bugs".

No, I mean for users to figure out why the type is wrong... You need the generic parameters for more complicated cases.

> Assuming by "diagnostics" you mean "figuring out compiler bugs". No, I mean for users to figure out why the type is wrong... You need the generic parameters for more complicated cases.
Author
Owner

In what situation is varXX useful in the error messages?
Maybe it should be also renamed to typevarXX? var is just too generic and it is unclear what it means.

In what situation is ``varXX`` useful in the error messages? Maybe it should be also renamed to ``typevarXX``? ``var`` is just too generic and it is unclear what it means.
Author
Owner
https://git.m-labs.hk/M-Labs/nac3/commit/ca07cb66cd1cc341bd64a8d8bc0e46cfbe5383aa
sb10q closed this issue 2022-04-12 10:36:16 +08:00
sb10q added this to the Alpha milestone 2022-04-12 11:09:02 +08:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3#166
No description provided.