[clang-tools-extra] [clangd] don't lower severity of clang-tidy modernize-* checks to remarks (PR #75706)

Julian Schmidt via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 2 06:30:05 PST 2024


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):
![image](https://github.com/llvm/llvm-project/assets/44101708/e66b4fc8-7e3a-4edb-8fbe-602bdce4a969)
'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):
![image](https://github.com/llvm/llvm-project/assets/44101708/16d7fb96-2cf7-4886-817e-5f141ff5de28)
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.
![image](https://github.com/llvm/llvm-project/assets/44101708/f420aa31-a49d-46d7-a71d-574f21211f8e)

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


More information about the cfe-commits mailing list