confusing error message when attempting to append to list #166
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: M-Labs/nac3#166
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It's pretty guaranteed that users will try to append to lists:
Unfortunately the error message is pretty bad:
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.
The message is better now, but non-deterministic.
Sometimes I get:
and sometimes:
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.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.
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.
Assuming by "diagnostics" you mean "figuring out compiler bugs".
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.No, I mean for users to figure out why the type is wrong... You need the generic parameters for more complicated cases.
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.ca07cb66cd