-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add clang tidy #12322
base: master
Are you sure you want to change the base?
Add clang tidy #12322
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12322 +/- ##
==========================================
- Coverage 82.49% 82.44% -0.05%
==========================================
Files 912 912
Lines 258083 258215 +132
==========================================
- Hits 212897 212880 -17
- Misses 45186 45335 +149
Flags with carried forward coverage won't be shown. Click here to find out more. |
Information: QA ran without warnings. Pipeline 24053 |
There is a build issue on non Linux. Cooking a fix. |
WARNING:
Pipeline 24055 |
I'm looking at how I can test this, and I'm struggling to make it work w/o getting flooded with warnings. E.g. trying a single file
|
I'm not using it in the command line but via the editor. If you have LSP via clangd activated (should be the default), it is going to pick the clang-tidy file without configuration and add some analysis to the file as warning. |
Hmm I would really like to figure out how else it can be made useful. If the clangd method can work, it should also be usable directly somehow. |
By adding this file, code analysis by clang-tidy is now available in LSP compatible editor using clangd. The CustomFunctions option that adds Suricata banned functions in the error list is only available with the (at the time of writing) future clang 20. Ticket: 3837
The exit() function is not thread safe and triggers a warning from clang tidy for all FatalError() and FatalErrorAtInit() calls. This patch uses quick_exit instead to only flush the critical IO and not call the static destructors (which are the non thread safe part).
This is generated at compile time so let's ignore.
Direct call to clang-tidy have more checks than through clangd and directly including headers is not in Suricata code style so it triggers a lot of unwanted errors.
clang-tidy did detect the -1 return value was not compatible with TmEcode enum.
It is complaining about circular import that are handled at build time. We have one single warning of the sort so let's silent it.
Discovered 2 things:
After small fixes on non Suricata accurate checks, we have around 76 warnings in suricata.c. |
This is reported by clang-tidy as non standard.
bpf_map_data was allocated in the function and not freed. Found by clang-tidy.
Spotted by clang-tidy.
Patched via `clang-tidy --quiet src/detect-http2.c --fix`
Including a C file is bug prone.
Default format style is not using clang-format so switching to 'file' to use clang-format.
Patch obtained via `clang-tidy --quiet src/reputation.c --fix`. On modification has not been applied: reputation.c:326:9: warning: macro 'SREP_SHORTNAME_LEN' defines an integral constant; prefer an enum instead [modernize-macro-to-enum] 326 | #define SREP_SHORTNAME_LEN 32 The change is not really making sense for a single value.
Patch generated by clang-tidy. Most hunks are `else after return` but there is also an unused parameter removed from FTPDataParse() function.
@victorjulien I've pushed some more commits on top of the MR. I've played a bit with the There is some checks that we could disable but I wanted you and the team to potentially take a look at them and take a decision. One annoying one is unused-parameters. It is useful in some cases but very verbose when there is API usage. |
This cause clang-tidy to exit with error if we encounter the warning about a potential memory leak.
I'm stopping playing with it. This is ready for review. |
Information: QA ran without warnings. Pipeline 24169 |
Information: QA ran without warnings. Pipeline 24170 |
Most the of the fixes look sane to me, though the linter annotations are a bit obnoxious I think. How are invoking things? I'm getting warnings like unknown |
Making sure I can see this be very useful, also in CI. So I guess I'd like to see a basic config that passes on our current code (with some fixes if needed). Then we can start an iterative process of adding more checks or making them stricter. |
Wonder also if we can just scan + fix just a single check at a time? E.g. this one would be nice to do now
|
Similar for this class of suggestions
|
Also liking
|
Do you have a compile_database.json ? (Can use bear of you don't have). Having it fixes most of the include issue.Le 12 janv. 2025 09:15, Victor Julien ***@***.***> a écrit :
Most the of the fixes look sane to me, though the linter annotations are a bit obnoxious I think.
How are invoking things? I'm getting warnings like unknown bool type which suggest that I'm missing something basic, like includes not getting picked up.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
This patchset adds a .clang-tidy file. It will be used by clangd to provide additional diagnostics in the code.
Some of the warnings especially the ones about using magic number are quite verbose but this may be a good idea to implement fixes to improve the situation.
Note: the forbidden functions part requires clang-20 (so compilation from git) to work
Contribution style:
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
Our Contribution agreements:
https://suricata.io/about/contribution-agreement/ (note: this is only required once)
Changes (if applicable):
(including schema descriptions)
https://redmine.openinfosecfoundation.org/projects/suricata/issues
Link to ticket: https://redmine.openinfosecfoundation.org/issues/3837
Describe changes: