1. The users of this style guide will probably expect that all of the rules that it prescribes will be enforced by eslint. However, this is not the case - there is a secret, non-documented segmentation where some rules are enforced and others are not, because they would be "too noisy on a legacy codebase". An example of a problematic rule like this is covered in issue #2020. I propose that all of

Since ESLint doesn't let us disable auto-fix for individual rules, and the capitalized-comments rule, while useful, can be annoying in editors when "auto-fix on save" is enabled.

SamVerschueren/vscode-linter-xo#78 (comment)

Expected behavior

Disable an annoying clang-tidy warning on linux

Steps to reproduce

1. Create a source file containing strncpy()
2. Observe that neomake complains
3. There is no way to disable this warning globally

In this case I would need to pass --checks=-clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling to clang-tidy

Adding this as args for the c ma

"Attribute itemprop not allowed on element link at this point"
I get this errors for things like that:
<link rel=icon itemprop=logo href=ico.png>
<link rel=canonical itemprop=url href="https://example.org/">

Otherwise the spec says
"Every HTML element may have an itemprop attribute specified"
https://html.spec.whatwg.org/multipage/microdata.html#names:-the-itemprop-attribute

Goo

Describe the issue
After upgrade to new Flutter stable (1.12.13), I got multiple unnecessary_final warnings. But when I remove these, I get similar amount of prefer_final_locals. What should I do? This definitely looks like a bug.

Expected behavior
There should not be any conflicting warnings.

Additional context
Dart 2.7.0, Flutter 1.12.13

Similar to eslint and others, could we have a comment to skip linting of specific blocks of code?

For instance, in eslint I could do this:

/* eslint-disable */

alert('foo');

/* eslint-enable */

https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments

Rubocop also has something similar

# rubocop:disable all
[...]
# rubocop:ena

It would be great if a rule exists that prevents that the generated code for a specific programming language is invalid because of the use of reserved names for fields.

I had a field named "default" which produces errors when generating code for c/c++