hls: report the same diagnostics as the CLI for a file - #1318
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files
🚀 New features to boost your workflow:
|
Both sides preprocess, parse and analyze a file the same way, then each collected the resulting codes separately - and the two collections had drifted apart. Preprocessor warnings reached `hemtt check` and never the editor: `pw1_redefine`, `pw2_invalid_config_case`, `pw3_padded_arg`, `pw4_include_case`, `pw5_undef_not_defined`. So did every config note and help, because the editor took only `warnings()` and `errors()` from the report while the CLI also pushed `notes_and_helps()`. `hemtt_sqf::check` and `hemtt_config::check` now own that middle. They fold `processed.warnings()` in with the lint codes, apply the CBA settings skip, and hand back the codes plus whatever the caller still needs. The ends stay where they were: the CLI compiles, rapifies and pushes to the addon, the language server renders LSP diagnostics and maintains its caches. This also fixes `Diagnostic::to_lsp`, which emitted one diagnostic per label using the parent code's message and severity. A secondary label therefore became a second diagnostic repeating the parent's message somewhere it did not apply: `PW1` marked the previous definition "redefining macro" as though it were the redefinition, and discarded the label's own "previous definition here". It now emits one diagnostic per primary label, falling back to all of them if a code has no primary. That applies to every multi-label diagnostic, not only `PW1`. Verified against a project built to trigger each case. `PW1`, `PW5` and `help[L-C12]` were reported by `hemtt check` and never published by the editor; they now appear in both, at the same locations.
LinkIsGrim
force-pushed
the
hls-cli-dedupe
branch
from
August 27, 2026 01:28
4f76f76 to
571a662
Compare
BrettMayson
approved these changes
Aug 31, 2026
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
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.
Both sides preprocess, parse and analyze a file the same way, then each collected the resulting codes separately.
Preprocessor warnings reached
hemtt checkand never the editor:pw1_redefine,pw2_invalid_config_case,pw3_padded_arg,pw4_include_case,pw5_undef_not_defined. So did every config note and help, because the editor took onlywarnings()anderrors()from the report while the CLI also pushednotes_and_helps().hemtt_sqf::checkandhemtt_config::checknow own that middle. They foldprocessed.warnings()in with the lint codes, apply the CBA settings skip, and hand back the codes plus whatever the caller still needs. The ends stay where they were: the CLI compiles, rapifies and pushes to the addon, the language server renders LSP diagnostics and maintains its caches.Diagnostic::to_lsp, emitted one diagnostic per label using the parent code's message and severity. A secondary label therefore became a second diagnostic repeating the parent's message somewhere it did not apply:PW1marked the previous definition "redefining macro" as though it were the redefinition, and discarded the label's own "previous definition here". It now emits one diagnostic per primary label, falling back to all of them if a code has no primary. That applies to every multi-label diagnostic, not onlyPW1.Verified against a project built to trigger each case.
PW1,PW5andhelp[L-C12]were reported byhemtt checkand never published by the editor; they now appear in both, at the same locations.