Enhancement Request: Support for Inline Warning Suppression with @stitch-ignore

[jhillacre]

I didn't find documentation in Stitch regarding inline suppression of specific problems, so I would like to suggest adding this functionality.

In a GameMaker project, I have functions that initialize dynamically but appear unused due to being called by gml_pragma rather than through a direct invocation. Stitch currently flags these as unused functions.

I'm proposing the ability to suppress specific Stitch warnings inline using comments, allowing developers to ignore particular warnings for specific lines or code blocks they've already reviewed.

Proposed Syntax:

1. Suppressing a Warning for the Next Line:

   // @stitch-ignore-next-line: unused-function
   offending_code();

2. Suppressing a Warning Inline:

   offending_code(); // @stitch-ignore: unused-function

3. Suppressing Multiple Warnings Inline:

   offending_code(); // @stitch-ignore: unused-function, deprecated-function

This feature would allow developers to maintain focused, intentional code analysis, which is especially useful in legacy projects where modernizing code could generate many non-critical warnings. It would help avoid the temptation to ignore warnings altogether by supporting case-by-case suppression, aligning Stitch with practices in other code analysis tools, such as eslint for JavaScript (offending() // eslint-ignore) or Flake8 for Python (offending() # noqa: E731).

If you made it this far, thank you for considering this enhancement request!

[adam-coster]

I totally agree that this would be a great feature! We deal with a lot of noise in our own legacy projects -- they're just so legacy that I haven't bothered because then we'd be putting ignores all over the place :P

There are a handful of related features for improving diagnostics that I'm hoping to get to at some point, but we're currently in the home stretch for our latest game project so I'm afraid I won't have time for a while!

Implementation for this sort of next-line (or current-line) suppression wouldn't be that difficult. The trickier bit is settling on a good design pattern at the outset so we can minimize incompatibility with Feather and otherwise don't regret the design choices.

I'm pretty sure Feather also has per-line diagnostic suppression, so probably I should go for feature parity there.

[adam-coster]

Yep, looks like Feather has it. I'm also used to the estlint/typescript style, so it looks a little funny to me without the @...

For my own future reference, the syntax is:

// Feather (ignore|disable) (?<issueType>GM\d+)

Not particularly user friendly, but I could add hover support on those codes to map the code back onto what it's for, and could hook into the VSCode API for autofixes (the lightbulb thingy) to add the right thing in the first place.

The first step would be mapping the current Stitch diagnostic cases onto the Feather ones. I think those are only listed in the GameMaker IDE itself, but if I can find those on disk somewhere that'd be ideal (like I do with the built-in functions via the GMLSpec.xml file).

So next steps look like this:

• Find the Feather code -> human-friendly description mapping on disk
  • If it's dynamically fetch-able, add code to do that and parse the file
  • If it's not, add a build script for parsing it and manually update it
• Map the current Stitch diagnostics onto the appropriate Feather codes
• Update the Stitch Parser to somehow consume these codes. Probably by adding them to statement contexts, and clearing that on subsequent statements?
• Update the Stitch Parser to include Feather code autocompletes in ignore-comments
• Update the VSCode side to
  • Add hovers for all Feather error codes (and indicate when they aren't supported by Stitch)
  • Add autofix for diagnostics, which would add a disabling-comment to the prior line
  • Ensure autocompletes for diagnostic codes work