I'm not sure we can add test cases for what the official compiler considers syntax errors:

for any s in ("a", 0): (s == 0) is an error because you can't mix types, but we don't catch it and I'm not sure we can without a fair bit of work.

for any s in ("a"): (s == 0) is an error because of the comparison between a string and an integer, which we currently don't catch.

I think to fix these would require a lot of work in the parser that probably isn't worth it?

I'm not sure we can add test cases for what the official compiler considers syntax errors:

for any s in ("a", 0): (s == 0) is an error because you can't mix types, but we don't catch it and I'm not sure we can without a fair bit of work.

for any s in ("a"): (s == 0) is an error because of the comparison between a string and an integer, which we currently don't catch.

I think to fix these would require a lot of work in the parser that probably isn't worth it?

I agree, gyp is only a parser, its mission is creating the AST for YARA rules, and such semantics checks are sometimes impossible. For example, the following two conditions are invalid for the same reason:

for any s in ("a"): (s == 0) 
for any s in ("a"): (s == x)  // where X is some external variable of type integer. 

With a parser like gyp you could be able to detect that the first condition is invalid, but the second one is impossible to detect unless you go beyond parsing, but that's actually outside the of the core mission for a parser.