generate errors/warnings in visitor

[pdawyndt]

• [ ] only built-in reporter blocks and boolean blocks exist; generate error when a custom reporter or custom boolean are used in Scratch-LN; exception: reporter blocks without arguments are considered as variables
• [ ] issue warning if non-existing ID is referenced
• [ ] issue warning if undefined block is used
• [ ] issue warning if no explicit reference is used when multiple blocks with the same signature are defined
• [ ] issue warning if invalid choice is chosen (e.g. when [some_unknown] key pressed)

[Ellen102]

• [ ] if a text input is used when a number input is expected (see #69 )

[Ellen102]

• [ ] a boolean input is expected but something else is used.

[Ellen102]

• [ ] using literals after define define bla {1} "s" #123

[Ellen102]

• [ ] using an ID twice

[pdawyndt]

• [ ] does Scratch-LN officially also supports the square brackets as a string delimiter, because this seems to work in the preview? I would expect a warning/error in this case.

[Ellen102]

Currently:

• adding blocks after forever/cap -> warning + start new stack
• hat block in the middle of stack -> warning + start a new stack
• A reporter/boolean block that does not exists e.g. (non existing {} bla bla ) -> generate variable + warning
• using without modifier -> warning that a modifier should be used + generate pink block
• generate a warning when not using a choice or expression or predicate inside a round shaped dropdown.
• when a built-in block is used without the right brackets. Generate a warning + render the most appropriate alternative.
• rectangle dropdown: verifies whether the option is valid if not generates a warning + show the text. verifies the type, if not a choice generate an error.

[Ellen102]

note for generating warnings when the wrong inputtype is used:

• this information is currently not present in block specifications, can be obtained from the toolbox.
• it is possible to put every shadow type in an empty place with the xml, and no problems.
• some shadow types are: math_number, math_integer, text

[Ellen102]

should say {1} generate a warning?

[pdawyndt]

I guess your idea was that say {1} can also be written as say "1" or as say {"1"} in line with the fact that Scratch does not make a difference between numbers and strings. In that respect, none of these alternatives should generate warnings.

Only if you can infer a difference between numbers and strings from the block context, I would generate warnings if a number is used where a string is expected or where a string is used where a number is expected. Together with the warnings, I would automatically cast the number into a string if a string is expected (this is always possible) and try to cast the string into a number if a number is expected (this is something that could fail; if it fails, I would issue an error instead of a warning if no sensible block conversion can be done).

[Ellen102]

I agree. There are more input types then just numbers. I am working on this function to verify the value. (not yet fully tested)