You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When parsing a type-def, we currently only store the name of the referenced type in the generated DataTypeDeclaration. If the aliased type does not exist, it is currently not possible to get back to the source-location of the definition, since we do not have a matching DataType in the index.
This leads to bad UX when validating undefined types, since the error messages shows on the user-type instead of where the actual error happened.
Additionally, ideally we would show such a validation for type-defs only once, instead of once per encountered user-type.
Here's an example:
TYPE myType : undeclaredType; END_TYPE
VAR_GLOBAL
a: myType;
END_VAR
The text was updated successfully, but these errors were encountered:
mhasel
changed the title
Unable to report an undeclared type if it is behind an type-def
Unable to report an undeclared type behind a type-def at the proper location
Oct 18, 2024
When parsing a type-def, we currently only store the name of the referenced type in the generated
DataTypeDeclaration
. If the aliased type does not exist, it is currently not possible to get back to the source-location of the definition, since we do not have a matchingDataType
in the index.This leads to bad UX when validating undefined types, since the error messages shows on the user-type instead of where the actual error happened.
Additionally, ideally we would show such a validation for type-defs only once, instead of once per encountered user-type.
Here's an example:
leads to
The text was updated successfully, but these errors were encountered: