5chmidti wrote: There is also the use-case to keep a relatively modern code-base in a modern state. In that case, the user might want to know about modernizations/deprecations right in the editor. Example (vscode):  'After removing the unused variable, I have no more problems/diagnostics', but the for-loop could be a range-for, and the function can use a trailing return type.
The mentioned 'inconsistency' is that vscode will not tell you about remarks as problems (right side of the `Problems` tab):  and the only way to find the diagnostics `modernize-` or `deprecated` is to find code with strike-throughs. Maybe a configuration option would be better? ```yaml Diagnostics: ModernizationDiagnosticSeverity: <> [W]DeprecatedDiagnosticSeverity: <> ``` or ```yaml Diagnostics: Severity: Modernize: <> Deprecated: <> ``` Or change the severity from `Remark` to `Note` (`getSeverity` shows that `Note` has a higher severity than `Remark`, which differs from `DiagnosticEngine::Level`/`DiagnosticIDs`), which will show up more visible and as a distinct entry in `Problems` and can be filtered by (screenshot above). The inline highlighting is kept even when filtering in the `Problems` tab.  This pr is probably not the way to do this, my personal take is that the configuration option is the most flexible. I guess an issue would have been a better fit to talk about this :) https://github.com/llvm/llvm-project/pull/75706 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
