Adding extra information in report for some issues#3
Merged
PeterSchops merged 135 commits intoSep 5, 2023
Merged
Conversation
I saw that cppcheck was sometimes showing extra information, on what exactly was wrong. And I found this very useful. The extra information is optional, and I'm finding it very helpful to pinpoint the problematic piece of code.
…information_in_error-report
Co-authored-by: chrchr-github <chrchr@github>
Owner
Author
|
How can I run this check locally, so that I can try to figure out why it is failing. |
changed reportError(...f"{..}") to reportError(..."{}".format{..})
… to yet another distro to get the latest version and updated the Chaotic-AUR key (cppcheck-opensource#5267) This is a mess. The version is AUR is still outdated and also doesn't install anymore. Fedora 38 carries the latest version of it so use that now. Keep the old steps in case we need to switch again in the future.
…`internalError` to overview (cppcheck-opensource#5283)
Owner
Author
|
It seems "....\cppcheck.exe --addon=misra --enable=style --inline-suppr --enable=information --error-exitcode=1 misra\misra-ctu-1-test.c misra\misra-ctu-2-test.c" is failing |
…rce#5287) I accidentally left this own when I rolled back a previous attempt to implement the conditional checks.
renamed extra to misra_severity, and added extra as last argument
Owner
Author
|
After updating reportError in cppcheckdata.py, the check was passing locally. Lets see if it also fixes the failing pipelines in github. |
…spect `--no-upload` in "nodata" uploads (cppcheck-opensource#5292) We were only matching each library once as the entry was removed from the container stored in the class as we did not modify a copy but a reference.
cppcheck-opensource#4975) I need to add parameters to some `check()` functions in the tests and things are already pretty messy with having to specify all the default values - readability aside. I found this on https://stackoverflow.com/a/49572324/532627 - apparently the CC BY-SA license by StackOverflow allows the usage within GPL.
Cppcheck does not report that cppcheck build dir does not exist and also does not report any write issues to the non-existent directory. This means that cppcheck build dir is actually not used. We should either create the directory or fail.
…-opensource#4868) This avoid lots of unchecked pointer dereferences. There was a single case which checked it and that looked like a leftover. The only way this might have been a `nullptr` pointer was through several default constructors which were not used at all so I removed them.
…ime (cppcheck-opensource#5259) Just a little clarification.
…5374) These do not show up in the CI since we only scan the non-matchcompiled code.
…heck-opensource#5375) Analysis has slowed down a lot when there are many strings in an array.
…}} (cppcheck-opensource#5250) This fixes a crash with following error: ``` Traceback (most recent call last): File "/usr/local/share/Cppcheck/addons/runaddon.py", line 8, in <module> runpy.run_path(addon, run_name='__main__') File "<frozen runpy>", line 291, in run_path File "<frozen runpy>", line 98, in _run_module_code File "<frozen runpy>", line 88, in _run_code File "/usr/local/share/Cppcheck/addons/misra.py", line 4737, in <module> main() File "/usr/local/share/Cppcheck/addons/misra.py", line 4679, in main checker.parseDump(item) File "/usr/local/share/Cppcheck/addons/misra.py", line 4335, in parseDump self.executeCheck(902, self.misra_9_2, cfg) File "/usr/local/share/Cppcheck/addons/misra.py", line 4246, in executeCheck check_function(*args) File "/usr/local/share/Cppcheck/addons/misra.py", line 2104, in misra_9_2 misra_9.misra_9_x(self, data, 902) File "/usr/local/share/Cppcheck/addons/misra_9.py", line 414, in misra_9_x parser.parseInitializer(ed, eq.astOperand2) File "/usr/local/share/Cppcheck/addons/misra_9.py", line 320, in parseInitializer child = self.root.getChildByValueElement(self.ed) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'getChildByValueElement' ``` A minimal example and testcase is added. The extra check for nextChild seems to fix it, however i did not read the whole codebase, so maybe this creates other issues. --------- Co-authored-by: Tim Blume <tbl@sevenstax-intern.de>
Scanning the `cli` folder with `DISABLE_VALUEFLOW=1` `Tokenizer::dump()` will consume almost 25% of the total Ir count when an addon is specified. This is mainly caused by the usage of `std::ostream`. Encountered while profiling cppcheck-opensource#4958.
…o some related cleanups and tests (cppcheck-opensource#5037) Encountered while investigating https://trac.cppcheck.net/ticket/11708. This has been like this since the introduction of `internalError` in b6bcdf2 (almost ten years ago to the day). Logging internal errors which bail out(!) of the analysis simply to `std::cout` for them possibly never to be seen (and also not affected the exitcode) is pretty bad IMO. They should always be visible. I also removed the filename from the message as it is already available (and thus redundant) and its existence should be defined by the template.
…hod with same name and arguments exists both in base class and derived class) (cppcheck-opensource#5379)
…opensource#5378) This primarily adds the corresponding report in the GUI that we have in the command line already
…information_in_error-report
…information_in_error-report
…uted with --release in the ci when checking the integrity of the Makefile [skip ci] (cppcheck-opensource#5391)
…t repository branches (cppcheck-opensource#5377) This will prevent duplicated workflows from being invoked for pushes into pull requests made from branches in the root (`danmar`) repository branches.
…pcheck-opensource#5392) The Windows jobs are along the longer jobs to run (~14 minutes) by splitting these up we reduce the peak time to about half of that.
…or faster builds (cppcheck-opensource#4400) This used to be one of the longest running jobs because of the slow setup and linking. Now it will take only ~2 minutes if everything is cached with half the time taken up by the tests.
…nd builds from CI (cppcheck-opensource#5397) Windows XP Pro x64 was released on April 25, 2005 and consumer processors supporting x86-64 have been around almost as long. Although there are still 32-bit Windows images available there is not much of a point maintaining support for these. We also never did any x86 builds for non-Windows platforms in CI so we don't even know if we work on those. You might still be able to build 32-bit binaries via CMake.
…information_in_error-report
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I saw that cppcheck was sometimes showing extra information, on what exactly was wrong. And I found this very useful. The extra information is optional, and I'm finding it very helpful to pinpoint the problematic piece of code.