Implement promised diagnostic severity and per-file limits
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- backend-api-design
Research direction
Start by locating DiagnosticsConfig and the document pull, workspace pull, Problems, and legacy publication paths; the issue does not name their files. Review target/ci-submit/windows-diagnostic-policy-red.log to understand the four failing Windows regression cases. Implement validation, severity filtering before per-file caps, zero-as-unlimited behavior, live configuration refresh, and preservation of the restore-pending signal; done means all four cases pass while compiler diagnostics remain consistent across the listed paths.
Written by the indexing model from the issue text.
Description
The diagnostics specification promises min_severity and max_per_file, including hot reload. DiagnosticsConfig currently contains neither field and rejects both as unknown settings.
Four independent real Windows VSIX regression cases fail after passing actual SDK build oracles and baseline document/workspace/Problems checks in F# and C#. Each closed file has two compiler errors and one warning (FS0001/FS0020 or CS0029/CS0219). min_severity = "error" still returns three diagnostics instead of two; a per-file limit of one still returns three instead of one.
Required behavior: validate the settings, apply severity before the cap, treat zero as unlimited, refresh live configuration, and preserve compiler truth across document pulls, workspace pulls and Problems. Legacy publication must retain its internal restore-pending signal even when presentation policy hides the informational notice.
Evidence: target/ci-submit/windows-diagnostic-policy-red.log, zero passing and four failing cases; no product fix was attempted before confirming the failures.
- Dominant language
- TypeScript
- Stars
- 168
- Forks
- 9
- Avg merge
- 2h 49m
- Merged PRs (30d)
- 60
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Nimblesite/SharpLsp
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Nimblesite/SharpLsp#468 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Nimblesite/SharpLsp#461 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Nimblesite/SharpLsp#447 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Nimblesite/SharpLsp#444 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Nimblesite/SharpLsp#442 ·
Maintainers usually reply within 1 day
All issues in Nimblesite/SharpLsp
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
awesome-dsh-plugin/awesome-dsh-plugin#9184 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
farion1231/cc-switch#8829 ·
Maintainers usually reply within 1 day
-
[core-client] Remove unused hand-maintained transport helpers after the definition-table cutoverOpendoc-audit enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100