Add configuration option to disable individual diagnostics #347
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This implements the ability to disable specific diagnostics via the `disabled_diagnostics` configuration option. Users can now suppress diagnostics that may be incorrect or not applicable to their project by listing diagnostic codes (e.g., "S100", "T100") in their config. Changes: - Add `disabled_diagnostics` field to Settings struct in djls-conf - Add `disabled_diagnostics()` method to SemanticDb trait - Update collect_diagnostics() to filter disabled diagnostic codes - Add unit tests for diagnostic filtering logic - Update configuration documentation with available diagnostic codes The configuration can be set via: - LSP client initialization options - Project config files (djls.toml, .djls.toml, pyproject.toml) - User config file Resolves #340
…rity Replace the simple disabled_diagnostics list with a comprehensive Ruff-inspired diagnostic configuration system that provides fine-grained control over which diagnostics are enabled and their severity levels. Key features: - `select`: Enable diagnostics by code or prefix (e.g., "ALL", "S", "T", "S1") - `ignore`: Disable diagnostics by code or prefix (applied after select) - `severity`: Override severity levels (error, warning, info, hint) - Prefix matching: "S" matches all S100-S107, "T9" matches T900-T999, etc. Configuration examples: ```toml [tool.djls.diagnostics] select = ["ALL"] # Enable all diagnostics (default) ignore = ["S100", "T100"] # Disable specific codes [tool.djls.diagnostics.severity] S101 = "warning" # Change severity to warning S103 = "hint" # Change severity to hint ``` Implementation: - Add DiagnosticsConfig struct with select/ignore/severity fields - Implement prefix matching logic for diagnostic code patterns - Add DiagnosticSeverity enum with LSP conversion - Update collect_diagnostics() to filter and apply severity overrides - Add comprehensive tests for all configuration scenarios - Update documentation with detailed examples This provides a familiar interface for Python developers already using Ruff, while offering powerful control over the diagnostic experience. Resolves #340
Simplify diagnostic configuration by removing select/ignore in favor of a pure severity-based approach. This better matches how LSP users think about diagnostics and provides a clearer upgrade path for future CLI linting features. Changes: - Remove `select` and `ignore` fields from DiagnosticsConfig - Keep only `severity` HashMap with prefix matching support - Add "off" as a severity level to disable diagnostics - Implement longest-prefix-wins resolution (exact > longer > shorter) - Update to_lsp_severity() to return Option<Severity> - Refactor collect_diagnostics() to skip "off" diagnostics Configuration model: - All diagnostics default to "error" severity - Users configure severity per code or prefix pattern - More specific patterns override less specific ones Example configurations: ```toml [diagnostics.severity] # Disable specific codes S100 = "off" # Disable all template errors "T" = "off" # But show parser errors as hints T100 = "hint" # Complex: prefix + specific overrides "S" = "warning" # All S-series as warnings "S1" = "info" # S100-S199 as info S100 = "off" # S100 completely off ``` Benefits: - Simpler mental model (just severity levels) - No conceptual overlap between "ignore" and "severity = off" - Prefix matching provides bulk control - Clean separation for future CLI linting features - LSP-focused design Updated comprehensive tests and documentation to reflect new approach.
The severity field should not be public since we provide public API methods (get_severity and is_enabled) for accessing it. This follows proper encapsulation patterns already established in the Settings struct. Changes: - Make severity field private in DiagnosticsConfig - Update tests to use get_severity() instead of direct field access - Maintains proper pub/private boundaries throughout the codebase
The djls-conf crate should be purely about configuration types and should not depend on or reference LSP types. Move the to_lsp_severity conversion function to djls-ide where it's actually used. Changes: - Remove to_lsp_severity() method from DiagnosticSeverity in djls-conf - Add to_lsp_severity() function in djls-ide/diagnostics module - Update collect_diagnostics() to use the local conversion function - Move test for LSP conversion to djls-ide where it belongs This maintains proper architectural boundaries: - djls-conf: Pure configuration types, no LSP dependencies - djls-ide: IDE/LSP features, knows about LSP types - Conversion happens at the boundary between layers
The benchmark database needs to implement the new diagnostics_config method added to the SemanticDb trait. Return default configuration since benchmarks don't need custom diagnostic settings.
The djls-ide crate now imports DiagnosticSeverity from djls-conf for the to_lsp_severity conversion, so it needs djls-conf as a dependency.
The djls-bench crate uses DiagnosticsConfig in its SemanticDb implementation, so it needs djls-conf as a dependency.
Two test databases in djls-semantic also implement the Db trait and need the diagnostics_config method: - TestDatabase in blocks/tree.rs - TestDatabase in semantic/forest.rs Both return default config since tests don't need custom settings.
CodSpeed Performance ReportMerging #347 will not alter performanceComparing Summary
Footnotes |
The doctest was trying to directly construct DiagnosticsConfig with the now-private severity field. Remove it since we have comprehensive unit tests covering the same functionality. Doctests are better for simple usage examples rather than testing internal implementation details.
- Add #[must_use] to get_severity and is_enabled methods - Replace map().unwrap_or() with more idiomatic map_or()
- Add backticks to DiagnosticSeverity in doc comment - Format map_or call on single line per rustfmt
Move `to_lsp_severity()` from a free function to an extension trait method following the existing convention in the codebase. This places the LSP type conversion logic in `ext.rs` alongside other similar extension traits.
for more information, see https://pre-commit.ci
joshuadavidthomas
deleted the
claude/disable-individual-diagnostics-011CUm6TkLAFYekM98RX8rLg
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #340