Clang Diagnostic Flag Documentation Inconsistencies
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
While working on a [tool to better understand diagnostic flags](https://stlab.github.io/compiler-hardening-tests/), I uncovered several inconsistencies. This may be an issue of ambiguous documentation, but if so, there are many diagnostic messages that cannot be controlled.
For [dynamic-exception-spec][(https://stlab.github.io/compiler-hardening-tests/#-Wdynamic-exception-spec](https://clang.llvm.org/docs/DiagnosticsReference.html#wdynamic-exception-spec)), I see "Some diagnostics enabled by default", but when I click on the one sub-flag it has ([deprecated-dynamic-exception-spec](https://clang.llvm.org/docs/DiagnosticsReference.html#wdeprecated-dynamic-exception-spec)) I expected to see "Enabled by default", but do not.
It could be that "some diagnostics" does not imply "some sub-flags" but that would mean there is no granular control over some default diagnostics.
The complete report of inconsistencies is here:
https://github.com/stlab/compiler-hardening-tests/blob/sean-parent/inconsistency-report/inconsistency_report.md
Disclaimer: this report and the code that generated it are entirely written by AI; it has only been spot-checked for accuracy.
Contributor guide
Research direction
Start with the DiagnosticsReference entries for -Wdynamic-exception-spec and -Wdeprecated-dynamic-exception-spec, then compare the reported cases in inconsistency_report.md. Determine whether the differing default-status wording is intentional and whether the documentation accurately describes granular diagnostic control; done means the inconsistencies have a documented resolution.
Written by the indexing model from the issue text.
Assessment
- Domain
- compilers, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100