PoC_add_new_pragma_lint_v2

[gorsing]

• PoC_v2
• PoC_v1 PoC_add_new_pragma_lint_v1 #22717

Motivation

Currently, developers rely on external tools like D-Scanner to catch semantic anti-patterns and style issues. However, external AST-based linters lack access to the compiler's symbol table and type resolution, which leads to false positives/negatives for complex semantic rules.
At the same time, introducing new semantic checks as compiler warnings (-w) has historically been rejected because it breaks existing codebases and CI pipelines.

Solution

This PR introduces a dedicated, strictly opt-in linter infrastructure integrated directly into the frontend via pragma(lint).

• Zero Breakage: Lint messages use a new ErrorKind.lint diagnostic that strictly does not increment global.errors or global.warnings. Compiling with -w or -we will never fail if a lint rule is triggered.
• Lexical Scoping: pragma(lint, ruleName) integrates tightly with Scope and applies lexically. It can be toggled on/off (none, all) per-module, per-aggregate, or per-function, respecting D's philosophy of explicit control.
• Tooling Integration: Lint diagnostics are fully compatible with the existing SARIF output, making it ready for modern IDEs and CI/CD environments.

Proof of Concept Rule (constSpecial)

To demonstrate the infrastructure, this PR includes one zero-false-positive rule: constSpecial. It emits a lint message when special struct methods (opEquals, toHash, opCmp, toString) are declared without const. Since this check sits in semantic3.d (visit(FuncDeclaration)), it leverages the compiler's perfect knowledge of types and correctly ignores compiler-generated thunks (!funcdecl.isGenerated()).

Example usage:

pragma(lint, constSpecial):

struct S {
    // Triggers: "Lint: special method `opEquals` should be marked as `const`"
    bool opEquals(ref const S other) { return true; } 
}

pragma(lint, none): // Disable for subsequent declarations

Proof of Concept Rule (unusedParams)

Example usage:

pragma(lint, unusedParams):

class A
{
    void foo(int x)
    {
    }
}

Future Impact

If accepted, this lays the groundwork for migrating highly requested, semantically heavy checks (e.g., unused parameters, redundant expressions, catching base Exception or UnusedParams) directly into the compiler, without disrupting the ecosystem or forcing warnings on users who don't want them.

[dlang-bot]

Thanks for your pull request and interest in making D better, @gorsing! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#22840"

[rikkimax]

So the design for the pragma with parameters was for a struct:

module core.lint;
struct LintParams {
    bool enabled = true;
    bool unusedParams = true;

    static LintParams off() => LintParams(enabled: false);
}

module mything;
import core.lint;
pragma(lint, LintParams(unusedParams: false));

Linters should support other types than just booleans for configuration, and this gives us the ability to change it, and quite importantly, store the struct configured to a project's desires in a single place.

module defs;
import core.lint;
enum MyLintParams = LintParams(unusedParams: false);

moduler lib;
import defs;
pragma(lint, MyLintParams);

[xoxorwr]

I don't think it's wise to bake linter configuration into the source code, it should be defined at build time via compiler flag IMO.

-vet:unused_params,unused_imports,const_special

Compiler flag let your build system apply appropriate strictness per stage: strict in production builds, relaxed in development, skipped entirely for legacy compatibility branches etc.

Last thing we want is version spaghetti with them.

Other than that, I think it's a great feature.

[gorsing]

So the design for the pragma with parameters was for a struct:

module core.lint;
struct LintParams {
    bool enabled = true;
    bool unusedParams = true;

    static LintParams off() => LintParams(enabled: false);
}

module mything;
import core.lint;
pragma(lint, LintParams(unusedParams: false));

Linters should support other types than just booleans for configuration, and this gives us the ability to change it, and quite importantly, store the struct configured to a project's desires in a single place.

module defs;
import core.lint;
enum MyLintParams = LintParams(unusedParams: false);

moduler lib;
import defs;
pragma(lint, MyLintParams);

@rikkimax Thanks for feedback. I convert this example to tests for coverage.