Semgrep: Ruby parse errors

[mschwager]

Closing out #2231, so I'm creating this issue to track additional known Ruby parsing bugs.

• [x] 'not pattern match' operator: https://github.com/tree-sitter/tree-sitter-ruby/issues/143
• [x] uppercase literal prefixes: https://github.com/tree-sitter/tree-sitter-ruby/issues/144
• [x] hex ASCII character code: https://github.com/tree-sitter/tree-sitter-ruby/issues/145
• [x] loop iterator: https://github.com/tree-sitter/tree-sitter-ruby/issues/146

Once these are fixed upstream we can pull in the changes and close this out :+1:

[nbrahms]

cf. https://github.com/tree-sitter/tree-sitter-ruby/pull/153

[nbrahms]

cf. https://github.com/tree-sitter/tree-sitter-ruby/pull/154

[nbrahms]

@mschwager @minusworld Should https://github.com/tree-sitter/tree-sitter-ruby/issues/155 affect our GA?

[mschwager]

@mschwager @minusworld Should tree-sitter/tree-sitter-ruby#155 affect our GA?

Ruby support is already GA'ed. Or do you mean demote Ruby maturity? Considering this bug doesn't violate any of our maturity definitions, I'd vote no. IMO we can treat it like a parsing bug in any other GA language.

[nbrahms]

@mschwager @minusworld Should tree-sitter/tree-sitter-ruby#155 affect our GA?

Ruby support is already GA'ed. Or do you mean demote Ruby maturity? Considering this bug doesn't violate any of our maturity definitions, I'd vote no. IMO we can treat it like a parsing bug in any other GA language.

This won't cause parse errors. Instead, it will cause certain patterns not to match code that you might expect them to.

[mschwager]

Hmm, your question is telling me that you think we should. Could you elaborate on your thoughts?

I would still lean toward "no" for the following reasons:

• We haven't had any complaints from external users, or internal users, for that matter, we found it through manual code review/debugging. This makes me think that it's not a widespread issue.
• IMO, we should prefer to fix bugs in GA languages vs. demoting them. Demoting feels like moving backward instead of forward.
• Again, this doesn't violate any of our maturity definitions. We can always update the definitions, but I'm having a tough time thinking of a generalized, quantifiable rule for this. I.e. how is this different than a false negative bug in any of our other GA languages? Ensuring no false negatives is a tall order :)

What do you think?

[aryx]

I think most of the things have been merged with https://github.com/returntocorp/semgrep/pull/2531, and ruby is at 99.944% I think.