<p>Most every linter has an option to &quot;ignore&quot; some parts of the code:</p>
<pre><code>/* @eslint-ignore-next-line semi */
// @phpstan-ignore
// @ts-ignore
# noqa: E731
etc.
</code></pre>
<p>I'm wondering how these could be implemented. It seems to not simply be removing the next line from the source code, since other lines effected still work. For example, ESLint doesn't report &quot;unused variable&quot; errors when the only place a variable is used is in an ignored line.</p>
<p>Is there some kind of dual parsing mode that allows parsing a line bug ignoring any errors on that line? How is this typically implemented?</p>

<static-analysis>
How is "Ignore next line" implemented in linters?
CC BY-SA 4.0
2023-12-11T20:03:36.030Z
Could this not just be as simple as creating diagnostics normally, then filtering the ones where the source span is on an ignored line?
Bbrk24
<p>The typical approach is that these annotations suppress <em>reporting</em> of problems, rather than their detection. Once potential issues have been found, only those that don't have something suppressing them are printed out. Those filters can then also be quite fine-grained about which lines, which classes of error, or which variables are included or excluded.</p>
<p>For example, ESLint <a href="https://github.com/eslint/eslint/blob/90077199fe519953f9af8664bf947db4e4958514/lib/linter/apply-disable-directives.js#L397" rel="noreferrer">gathers the list of <code>disable</code> directives and matches them with detected problems</a>, suppressing reporting of the ignored issues. TypeScript <a href="https://github.com/microsoft/TypeScript/blob/0c2dea58c726ffee40b6caf833ff69ea5278aeb7/src/compiler/program.ts#L2927" rel="noreferrer">does the same thing</a></p>
<blockquote>
<pre class="lang-js prettyprint-override"><code>// Diagnostics are only reported if there is no comment directive preceding them
// This will modify the directives map by marking &quot;used&quot; ones with a corresponding diagnostic
</code></pre>
</blockquote>
<p>A significant benefit of this approach over repressing the detection in the first place is that <strong>diagnostics can also be given for ignored issues that <em>aren't actually present</em></strong>; that can also be a sign of a problem, or just an opportunity to remove a marker that's no longer required.</p>
<p>There is no special parsing mode required, and generally no actual parsing involved: the linter operates on either already-parsed syntax trees or on the raw source text (or both) depending on the nature of the checks.</p>
<p>Disabling analyses at the whole-file or whole-codebase level more often does turn off running them at all, because the running cost can be spared and the benefits of reporting unneeded suppressions at that level are limited. If there is a particularly expensive single-line analysis (something interprocedural, perhaps), then it could make sense to allow turning it off individually as well, but I can't think of an instance of that off-hand; possibly loop termination checking could be an example, but that's less often a linter matter.</p>

CC BY-SA 4.0
2023-12-11T20:54:35.620Z
2023-12-11T20:54:35.620Z
Michael Homer
CC BY-SA 4.0
2023-12-11T22:20:00.720Z
„diagnostics can also be given for ignored issues that aren't actually present“ – `@ts-expect-error` does exactly that, and I find it immensely useful.
Jörg W Mittag
# How is "Ignore next line" implemented in linters?
Posted by: username_0 on 2023-12-11
Most every linter has an option to "ignore" some parts of the code:
/* @eslint-ignore-next-line semi */
// @phpstan-ignore
// @ts-ignore
# noqa: E731
etc.

I'm wondering how these could be implemented. It seems to not simply be removing the next line from the source code, since other lines effected still work. For example, ESLint doesn't report "unused variable" errors when the only place a variable is used is in an ignored line.
Is there some kind of dual parsing mode that allows parsing a line bug ignoring any errors on that line? How is this typically implemented?
**Tags:** static-analysis
> **Comments:**
> **username_1**: Could this not just be as simple as creating diagnostics normally, then filtering the ones where the source span is on an ignored line?  
---
## 1 answers
### Answer by username_2 on 2023-12-11. Score: 10
The typical approach is that these annotations suppress reporting of problems, rather than their detection. Once potential issues have been found, only those that don't have something suppressing them are printed out. Those filters can then also be quite fine-grained about which lines, which classes of error, or which variables are included or excluded.
For example, ESLint gathers the list of disable directives and matches them with detected problems, suppressing reporting of the ignored issues. TypeScript does the same thing

// Diagnostics are only reported if there is no comment directive preceding them
// This will modify the directives map by marking "used" ones with a corresponding diagnostic


A significant benefit of this approach over repressing the detection in the first place is that diagnostics can also be given for ignored issues that aren't actually present; that can also be a sign of a problem, or just an opportunity to remove a marker that's no longer required.
There is no special parsing mode required, and generally no actual parsing involved: the linter operates on either already-parsed syntax trees or on the raw source text (or both) depending on the nature of the checks.
Disabling analyses at the whole-file or whole-codebase level more often does turn off running them at all, because the running cost can be spared and the benefits of reporting unneeded suppressions at that level are limited. If there is a particularly expensive single-line analysis (something interprocedural, perhaps), then it could make sense to allow turning it off individually as well, but I can't think of an instance of that off-hand; possibly loop termination checking could be an example, but that's less often a linter matter.
> **Comments:**
> **username_3** (2023-12-11): „diagnostics can also be given for ignored issues that aren't actually present“ – `@ts-expect-error` does exactly that, and I find it immensely useful.  
---
