{ "tokens": { "input": 144506, "cache_read": 2834200, "cache_write": 708550, "output": 34269 }, "reviews": [ { "key": [ "https://ftp.debian.org/debian/pool/main/b/bandage/bandage_0.9.0.orig.tar.gz", "your Bandage-0.9.0/ogdf/basic/Graph_d.h:1205:7: style: The member function 'ogdf::Graph::sort < ogdf :: List < AdjElement * > >' can be static. [functionStatic]\n Bandage-0.9.0/ogdf/basic/Graph_d.h:1205:7: note: The member function 'ogdf::Graph::sort < ogdf :: List < AdjElement * > >' can be static.\n Bandage-0.9.0/ogdf/basic/Graph_d.h:1205:7: note: The member function 'ogdf::Graph::sort < ogdf :: List < AdjElement * > >' can be static." ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "With the PR, Cppcheck deduces the template argument from the variable passed to the call. That instantiates `Graph::sort>`, which was previously never instantiated (only literal arguments were deduced before). The body only does `v->m_adjEdges.sort(newOrder)` (plus asserts on `v` in debug builds). It never touches `this` or any member of `Graph`. Friend access to `NodeElement` internals also works from a static member function, so the 'can be static' finding is technically correct. It is the same pattern as `reverseAdjEdges`. The function name in the message carries the expanded template-id, which is the usual format for instantiated templates. Overall this is a true positive gained through better template coverage." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/c/coot/coot_1.1.18+dfsg.orig.tar.xz", "your coot-1.1.18+dfsg/coot-utils/tree.hh:626:60: warning:inconclusive: Member variable 'tree < coot :: linked_residue_t , std :: allocator < tree_node_ < coot :: linked_residue_t > > >::alloc_' is not assigned a value in 'tree < coot :: linked_residue_t , std :: allocator < tree_node_ < coot :: linked_residue_t > > >::operator='. [operatorEqVarError]" ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "The new warning says that `alloc_` is not assigned in `tree::operator=`. `alloc_` is the tree's allocator, here a `std::allocator`, which is stateless. Container assignment normally does not copy the allocator (`propagate_on_container_copy_assignment` is false for `std::allocator`), so leaving it out of `operator=` is correct and the warning is a false positive. The same warning also appears twice for one class, once as `coot::linked_residue_t` and once as `linked_residue_t`. That suggests the new type deduction produced two differently named instantiations of the same template. This is a side effect of the PR's new instantiations, not a real bug found in coot." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/c/coot/coot_1.1.18+dfsg.orig.tar.xz", "your coot-1.1.18+dfsg/coot-utils/tree.hh:634:60: warning:inconclusive: Member variable 'tree < linked_residue_t , std :: allocator < tree_node_ < linked_residue_t > > >::alloc_' is not assigned a value in 'tree < linked_residue_t , std :: allocator < tree_node_ < linked_residue_t > > >::operator='. [operatorEqVarError]" ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "The new warning is on the move assignment operator of the tree class template. That operator deliberately keeps its own `head`/`feet` sentinel nodes and only relinks the moved node chain. `alloc_` is a stateless `std::allocator` that is meant to stay with the object, so not assigning it is correct and the warning is a false positive. It also appears twice, once for `tree` and once for `tree`. These are the same type instantiated under two spellings, which suggests the new deduction creates duplicate, inconsistently qualified instantiations rather than understanding the code better." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/e/emscripten/emscripten_6.0.5+dfsg+~1.41.5.orig.tar.xz", "main emscripten-core-emscripten-1db5137/test/third_party/bullet/src/BulletMultiThreaded/SpuNarrowPhaseCollisionTask/SpuGatheringCollisionTask.cpp:781:18: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable T [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "In main, the function template `DoSwap(T& a, T& b)` stayed uninstantiated. Its calls pass variables, not literals, so the old literal-only deduction could not deduce `T`. The leftover template body then caused a ValueFlow bailout on the incomplete variable `T`. The PR deduces template arguments from the argument types (the `T&` form is supported). That lets the template be instantiated with concrete types and the generic declaration removed. The bailout disappears because Cppcheck now analyses concrete code instead of skipping the raw template, so this is an improvement." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/e/emscripten/emscripten_6.0.5+dfsg+~1.41.5.orig.tar.xz", "main emscripten-core-emscripten-1db5137/test/third_party/cubescript/command.cpp:246:41: style: Argument 'min' shadows outer function [shadowFunction]\n emscripten-core-emscripten-1db5137/test/third_party/cubescript/tools.h:53:17: note: Shadowed function\n emscripten-core-emscripten-1db5137/test/third_party/cubescript/command.cpp:246:41: note: Shadow argument" ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "`fvariable` has a parameter named `min`, and tools.h:53 declares a function `min` (very likely a template like `template T min(T a, T b)`). Inside `fvariable` the parameter really does hide that function, so the shadowFunction warning was a true positive. The PR now deduces template arguments from variable arguments (e.g. `min(a, b)`). Cppcheck therefore instantiates `min` etc. and removes the original template declaration. The shadow check no longer finds a function named `min`, so the warning disappears. The code did not change and Cppcheck does not understand it better; the warning was lost as a side effect of the template being removed. That is a lost true positive, though a low-value style one." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/e/emscripten/emscripten_6.0.5+dfsg+~1.41.5.orig.tar.xz", "your emscripten-core-emscripten-1db5137/test/third_party/cubescript/command.cpp:954:27: style: Parameter 'start' can be declared as pointer to const. However it seems that 'substr' is a callback function, if 'start' is declared with const you might also need to cast function pointer(s). [constParameterCallback]\n emscripten-core-emscripten-1db5137/test/third_party/cubescript/command.cpp:970:1: note: You might need to cast the function pointer here\n emscripten-core-emscripten-1db5137/test/third_party/cubescript/command.cpp:954:27: note: Parameter 'start' can be declared as pointer to const" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "In `substr`, `start` is an `int*` that is only read: `*start` is passed to `clamp(*start, 0, len)`. Before the PR the call to the function template `clamp` had non-literal arguments, so it was not instantiated. Cppcheck therefore could not rule out that `*start` was bound to a non-const reference, and stayed silent. With type deduction, `clamp` is instantiated with by-value parameters, so Cppcheck sees that `*start` is never modified. `const int *start` is therefore valid. The message also correctly notes that `substr` is used as a callback via `COMMAND(substr, \"sis\")`. This is a newly found true positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/g/gromacs/gromacs_2026.4.orig.tar.gz", "main gromacs-2026.4/src/gromacs/mdlib/broadcaststructs.h:69:22: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable T [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "`block_bc` is a function template with a `T&` parameter. It is called with plain variables, for example `block_bc(comm, ir->x)`. Before this PR, Cppcheck only deduced template arguments from literals. The template therefore stayed uninstantiated, and ValueFlow bailed out on the incomplete type `T`. The PR deduces `T` from the argument's ValueType, so the template is now instantiated with concrete types and the original template is removed. The debug bailout disappears because Cppcheck understands the code better. One caveat: enum arguments may be deduced as their underlying integer type, which is slightly imprecise but harmless here." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/g/gromacs/gromacs_2026.4.orig.tar.gz", "your gromacs-2026.4/src/external/colvars/colvarscript.cpp:924:19: style: The member function 'colvarscript::set_result_rvector' can be static. [functionStatic]\n gromacs-2026.4/src/external/colvars/colvarscript.h:238:7: note: The member function 'colvarscript::set_result_rvector' can be static.\n gromacs-2026.4/src/external/colvars/colvarscript.cpp:924:19: note: The member function 'colvarscript::set_result_rvector' can be static." ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "`set_result_rvector` calls the member function template `set_result_text(x, obj)`. That template forwards to the member `set_result_text_from_str`, which stores the result in the script object, so the function cannot really be static. The sibling functions that call `set_result_text`, `set_result_text` and so on explicitly are not flagged, by main or by the PR. Only the call whose template argument the PR now deduces (`cvm::rvector`) gets the functionStatic warning. That inconsistency suggests the deduced and instantiated call is no longer recognised as a call to a non-static member, which makes this new warning a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/g/gromacs/gromacs_2026.4.orig.tar.gz", "your gromacs-2026.4/src/external/googletest/googletest/src/gtest-printers.cc:268:34: style: Condition '1<=c' is always true [knownConditionTrueFalse]\n gromacs-2026.4/src/external/googletest/googletest/src/gtest-printers.cc:262:9: note: Assuming that condition 'c==0' is not redundant\n gromacs-2026.4/src/external/googletest/googletest/src/gtest-printers.cc:268:34: note: Condition '1<=c' is always true" ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "PrintCharAndCodeTo is a template that is instantiated for unsigned char, signed char and wchar_t. The new type deduction now creates the unsigned char instantiation. In that copy, after the `c == 0` early return, `1 <= c` is indeed always true. For signed char, and wchar_t on platforms where it is signed, c can be negative, so the condition is meaningful. A warning on the shared template source that only holds for one instantiation is a false positive. The PR guards a similar case in checkother (template-arg typed variables) but not this condition check." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/g/gromacs/gromacs_2026.4.orig.tar.gz", "your gromacs-2026.4/src/gromacs/ewald/pme_output.h:53:1: debug: SymbolDatabase couldn't resolve all user defined types. [debug]" ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "The PR adds a new debug message, 'SymbolDatabase couldn't resolve all user defined types', on struct PmeOutput. The struct has members like gmx::ArrayRef, real and matrix. Main does not report this, so the PR's symbol database handling (the incremental update or rebuild after template type deduction, and the moved finalize phases) now leaves some type unresolved here. A new debug message like this means Cppcheck understands the code worse than before." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/g/grub/grub_0.97.orig.tar.gz", "your grub-0.97/stage2/disk_io.c:596:8: warning: Uninitialized variable: *len [uninitvar]\n grub-0.97/stage2/disk_io.c:526:13: note: Calling function 'next_partition', 6th argument '&len' value is \n grub-0.97/stage2/disk_io.c:593:23: note: Assuming condition is true\n grub-0.97/stage2/disk_io.c:596:8: note: Uninitialized variable: *len" ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "The new warning is a false positive. `*len` is read inside `next_bsd_partition`, a GCC nested function in `next_partition`. In GRUB, the body of `next_partition` only calls `next_bsd_partition` when `*partition != 0xFFFFFF` and the previous slice is a BSD slice. By then an earlier call through `next_pc_slice` has already filled in `*len`. On the first call, where the caller's `len` is still uninitialized, the BSD path is never taken. Cppcheck reports a read of the uninitialized `*len` on a path that cannot happen. This is C code, so the PR's template work does not apply directly. The likely cause is the reordering of symbol-database phases (escape functions, need-initialization and expression ids now run in `finalize()`), which changed how the nested-function body is analysed." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/h/hipblas/hipblas_7.2.4.orig.tar.gz", "main hipblas/clients/common/norm.cpp:260:20: style: Variable 'HERM' is assigned a value that is never used. [unreadVariable]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "The constexpr variable HERM is used as a template argument in lapack_xlansy(...) on lines 261 and 264, so the unreadVariable warning was a false positive. The PR changes how templates and the symbol database are processed: it adds type deduction for template calls with variable arguments and defers parts of SymbolDatabase construction until after the template simplifier is done. That plausibly lets Cppcheck now see the use of HERM as a template argument. Removing this false positive is an improvement." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/j/jamulus/jamulus_3.9.1+dfsg.orig.tar.gz", "your jamulus-3.9.1+dfsg/src/server.cpp:328:36: error: Array 'vecChannels[150]' accessed at index -1108, which is out of bounds. [negativeIndex]\n jamulus-3.9.1+dfsg/src/server.cpp:312:29: note: Assignment 'iCurChanID=-860-246-1-1', assigned value is -1108\n jamulus-3.9.1+dfsg/src/server.cpp:328:36: note: Negative array index" ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "connectChannelSignalsToServerSlots() recurses down to the explicit specialization <0>, so slotId runs from MAX_NUM_CHANNELS (150) to 1 and iCurChanID = slotId - 1 is always within 0..149. The new warning claims index -1108, from 'iCurChanID=-860-246-1-1'. That value means Cppcheck instantiated the template with nonsense negative arguments: the recursion did not stop at the <0> specialization and kept going below zero. This is a bogus instantiation caused by the PR's template simplifier/symbol database changes, so the negativeIndex error is a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/j/jamulus/jamulus_3.9.1+dfsg.orig.tar.gz", "your jamulus-3.9.1+dfsg/src/server.cpp:328:36: error: Array 'vecChannels[150]' accessed at index -936, which is out of bounds. [negativeIndex]\n jamulus-3.9.1+dfsg/src/server.cpp:312:29: note: Assignment 'iCurChanID=-860-74-1-1', assigned value is -936\n jamulus-3.9.1+dfsg/src/server.cpp:328:36: note: Negative array index" ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "`connectChannelSignalsToServerSlots` recurses with `slotId - 1`. `slotId` is `unsigned int` and the explicit specialization `<0>` stops the recursion, so `iCurChanID = slotId - 1` ranges over 0..MAX_NUM_CHANNELS-1 and is never negative. The new warning reports `slotId` as a nonsense negative chain (`-860-74-1-1` = -936), so Cppcheck instantiated the template past the `<0>` specialization with impossible values. This negativeIndex error added by the PR is a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/j/jamulus/jamulus_3.9.1+dfsg.orig.tar.gz", "your jamulus-3.9.1+dfsg/src/server.cpp:334:36: error: Array 'vecChannels[150]' accessed at index -1844, which is out of bounds. [negativeIndex]\n jamulus-3.9.1+dfsg/src/server.cpp:312:29: note: Assignment 'iCurChanID=-860-982-1-1', assigned value is -1844\n jamulus-3.9.1+dfsg/src/server.cpp:334:36: note: Negative array index" ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "connectChannelSignalsToServerSlots() recurses with slotId-1 and stops at the explicit specialization for 0. So iCurChanID = slotId-1 always lies in 0..MAX_NUM_CHANNELS-1 and the index is never negative. The message shows slotId values like '-860-982', which means the template simplifier made broken instantiations with negative template arguments. It ignored or mishandled the <0> specialization, probably because the PR changed specialization handling and re-runs the simplifier. The new negativeIndex error is a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/k/kmc/kmc_3.2.4+dfsg.orig.tar.xz", "your KMC-3.2.4/kmc_api/kmer_api.h:503:14: style: The member function 'CKmerAPI::from_string' can be static. [functionStatic]" ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "`from_string(const std::string&)` calls the member template `from_string_impl(kmer_string.begin(), len)`, which writes the k-mer into instance members such as `kmer_data`, so the function cannot be static. The PR now deduces the argument types of the other call, `from_string_impl(kmer_string, len)` with a `const char*`, and instantiates and removes the template. The `std::string::iterator` argument cannot be deduced (ITERATOR is not supported), so this call is left pointing at a removed template. Cppcheck then no longer sees a non-static member call and reports a new false positive functionStatic." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/k/kmc/kmc_3.2.4+dfsg.orig.tar.xz", "your KMC-3.2.4/kmc_tools/kmc1_db_reader.h:522:9: style: The scope of the variable 'bundle_size' can be reduced. [variableScope]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "In `fill_suffix()`, `bundle_size` is copied from `suffix_bundle_insert.size` at function scope. Its only use is `if (bundle_pos == bundle_size)` inside the `if (local_suffix_buff_pos)` block. The declaration can be moved into that `if` block, before the loop, without changing behaviour, so the variableScope warning is technically correct. The PR now deduces the function template calls in this code (e.g. `build_counter`), which most likely let the check analyse this function. The new warning is therefore a valid style finding rather than a false positive. It is low-value, since copying members into locals is a deliberate pattern here." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/k/kmc/kmc_3.2.4+dfsg.orig.tar.xz", "your KMC-3.2.4/kmc_tools/kmc1_db_reader.h:640:3: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable counter [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "regression", "confidence": "low", "explanation": "Line 640 expands the FILL_BUNDLE_LOOP_UNROLL_CODE macro, which assigns to `counter`. That is an ordinary local variable of the fill-bundle member function. Main had no bailout here, so it knew `counter`. With the PR, ValueFlow now treats `counter` as an incomplete variable (a name with no variable id and not known as a type) and skips the whole function. A similar new bailout appears at line 541 in the same file. This points to the PR's re-tokenization after type deduction (incremental or full rebuild of var ids and the symbol database) leaving `counter` unresolved, so Cppcheck understands this function worse. The variable's declaration is not shown, so the exact cause cannot be confirmed." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/k/kmc/kmc_3.2.4+dfsg.orig.tar.xz", "your KMC-3.2.4/kmc_tools/kmer_file_header.h:84:28: style: The member function 'CKmerFileHeader::load_uint < unsigned char >' can be static. [functionStatic]\n KMC-3.2.4/kmc_tools/kmer_file_header.h:84:28: note: The member function 'CKmerFileHeader::load_uint < unsigned char >' can be static.\n KMC-3.2.4/kmc_tools/kmer_file_header.h:84:28: note: The member function 'CKmerFileHeader::load_uint < unsigned char >' can be static." ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "`load_uint` is a private member template that only uses its parameters (`file`, `res`) and no members, so it really can be static. Before the PR, calls like `load_uint(file, var)` were never instantiated, because only literal arguments were deduced, so the body was never checked. The new deduction from variable types instantiates it for `uint8`, `uint32` and `uint64`, and functionStatic now reports a valid style issue. One downside: the same line is reported once per instantiation (three warnings), which is a bit noisy, but each warning is correct." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/k/kmc/kmc_3.2.4+dfsg.orig.tar.xz", "your KMC-3.2.4/kmc_tools/kmer_file_header.h:84:28: style: The member function 'CKmerFileHeader::load_uint < unsigned long >' can be static. [functionStatic]\n KMC-3.2.4/kmc_tools/kmer_file_header.h:84:28: note: The member function 'CKmerFileHeader::load_uint < unsigned long >' can be static.\n KMC-3.2.4/kmc_tools/kmer_file_header.h:84:28: note: The member function 'CKmerFileHeader::load_uint < unsigned long >' can be static." ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "`load_uint` is a private member template. It only uses its parameters (`file`, `res`) and never touches `this` or any member, so it can indeed be static. Main never instantiated it, because it is called with variables (e.g. `load_uint(file, var)`) and old deduction only handled literal arguments. The PR now deduces `T` from variable types, expands the instantiations, and the `functionStatic` check can see them. This is a new true positive. One drawback: it is reported once per instantiation at the same line, which is noisy, but each report is correct." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/k/kphotoalbum/kphotoalbum_6.2.0.orig.tar.xz", "your kphotoalbum-6.2.0/MainWindow/ExternalPopup.h:26:1: debug: SymbolDatabase couldn't resolve all user defined types. [debug]" ], "verdict": { "verdict": "regression", "confidence": "low", "explanation": "The PR adds a new debug message, \"SymbolDatabase couldn't resolve all user defined types\", on class ExternalPopup. The class derives from the external QMenu and uses types such as DB::ImageInfoPtr and KService::List. None of these changed, yet main did not report this debug message. The new type-deduction rounds rebuild or incrementally update the symbol database after creation, and the message most likely comes from that rebuild or update. A rebuild can leave type pointers unresolved, or emit a debug check that main never reached. The PR adds no new understanding of this header, so a new debug message points to slightly worse or noisier symbol resolution. It matters little to users, but by the review criteria a new debug message counts as a regression." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/l/ltt-control/ltt-control_2.16.0.orig.tar.bz2", "your lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: style: The member function 'fmt::v11::format_int::format_signed < int >' can be static. [functionStatic]\n lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: note: The member function 'fmt::v11::format_int::format_signed < int >' can be static.\n lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: note: The member function 'fmt::v11::format_int::format_signed < int >' can be static." ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "format_signed calls the member template format_unsigned(abs_value), which writes into the member buffer_, so format_signed uses the object and cannot be static. The PR now deduces format_signed from the constructor calls and instantiates it. The inner call, however, takes an argument of type detail::uint32_or_64_or_128_t, so format_unsigned is apparently not resolved as a member call. That makes Cppcheck wrongly conclude the instantiation does not use 'this'. The new functionStatic warning is a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/l/ltt-control/ltt-control_2.16.0.orig.tar.bz2", "your lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: style: The member function 'fmt::v11::format_int::format_signed < long >' can be static. [functionStatic]\n lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: note: The member function 'fmt::v11::format_int::format_signed < long >' can be static.\n lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: note: The member function 'fmt::v11::format_int::format_signed < long >' can be static." ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "`format_signed` calls `format_unsigned(abs_value)`, and `format_unsigned` writes to the member array `buffer_`. So `format_signed` uses instance state and cannot be static. The new type deduction instantiates `format_signed` from the constructor calls. However, the argument type of the inner call is `detail::uint32_or_64_or_128_t`, which cannot be deduced. So the inner call to the member template `format_unsigned` is left unresolved, and the functionStatic check wrongly concludes the function uses no members. This is a new false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/l/ltt-control/ltt-control_2.16.0.orig.tar.bz2", "your lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: style: The member function 'fmt::v11::format_int::format_signed < long long >' can be static. [functionStatic]\n lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: note: The member function 'fmt::v11::format_int::format_signed < long long >' can be static.\n lttng-tools-2.16.0/src/vendor/fmt/format.h:3932:24: note: The member function 'fmt::v11::format_int::format_signed < long long >' can be static." ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "The PR now instantiates `format_signed` from the constructor call via type deduction. That instantiation calls the member template `format_unsigned(abs_value)`, which writes to the non-static member `buffer_`. So `format_signed` uses instance state and cannot be static. Cppcheck evidently did not resolve the `format_unsigned` call inside the new instantiation: `abs_value` is `auto` deduced from a type trait, so its type cannot be deduced. As a result it reported functionStatic, which is a new false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/libs/libstaroffice/libstaroffice_0.0.8.orig.tar.xz", "your libstaroffice-0.0.8/src/lib/libstaroffice_internal.hxx:169:13: warning: Comparison of a boolean expression with an integer. [compareBoolExpressionWithInt]" ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "`checkAddOverflow` is a generic overflow check for numeric types. The PR's new type deduction from argument expressions now instantiates it, and the new warning fires on `x < 0` (column 13), which implies `x` is treated as bool. libstaroffice uses this helper for integer additions, so a bool instantiation is very unlikely to be real. Either the deduction picked bool from a wrong argument ValueType, or the instantiated expression `x < 0 && y < std::numeric_limits::lowest() - x` was mis-parsed. The call sites are not shown, so this cannot be fully confirmed, but the new warning is most likely a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/mriconvert/mriconvert_2.1.0.orig.tar.gz", "your ByteSwap.h:18:13: portability:inconclusive: Casting from float * to char * is not portable due to different binary data representations on different platforms. [invalidPointerCast]" ], "verdict": { "verdict": "improvement", "confidence": "low", "explanation": "The PR's new type deduction instantiates `ByteSwap` for a float argument (T = float). `reinterpret_cast(&rBuffer)` is then a real `float*` to `char*` cast. invalidPointerCast reports casts to `char*` only as inconclusive, by design, because they are often intentional. The same warning would already appear for equivalent non-template code. Byte swapping does depend on the float's binary layout, which is the portability concern the message describes. So the new warning comes from Cppcheck understanding the template call better and matches the check's existing behaviour. It is borderline, though: casting to `char*` is legal and intended in a byte-swap routine, so some users will see it as noise." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/muse/muse_4.2.1.orig.tar.gz", "your muse-4.2.1/src/muse/widgets/mmath.cpp:62:26: style: Parameter 'array' can be declared as pointer to const [constParameterPointer]" ], "verdict": { "verdict": "improvement", "confidence": "high", "explanation": "`qwtGetMin` only reads `array` (`array[0]` and `array[i]` passed to `qwtMin`) and never writes through it, so `const double *array` is valid. `qwtMin` is presumably a function template in mmath.h taking its arguments by value or const reference (the header is not shown). Main could not instantiate the call `qwtMin(rv, array[i])` because the arguments are not literals. It therefore treated the call as possibly modifying the element and stayed silent. The PR deduces `qwtMin` from the argument types, sees the element is not modified, and correctly reports the missing const. This is a new true positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/m/muse/muse_4.2.1.orig.tar.gz", "your muse-4.2.1/src/muse/widgets/mmath.cpp:92:26: style: Parameter 'array' can be declared as pointer to const [constParameterPointer]" ], "verdict": { "verdict": "improvement", "confidence": "high", "explanation": "qwtGetMax only reads `array`: it reads `array[0]` and passes `array[i]` to `qwtMax(rv, array[i])`. `qwtMax` is a function template, presumably taking its arguments by value or const reference, as Qwt's helpers do. Before, cppcheck could not deduce `T` from the non-literal arguments, so the call stayed an unknown template call and the `array` element might have been modified. Now `T` is deduced as `double` and the call is instantiated, so cppcheck sees that `array` is never written through. `const double *array` is correct, so this is a new true positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/n/numpy/numpy_2.4.6+ds.orig.tar.xz", "main numpy-2.4.6/numpy/_core/src/highway/hwy/base_test.cc:471:24: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable T [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "Line 471 is inside the function template `TestEndianGetIntegerVal(T val)`. It is only called through the macro with typed arguments such as `int8_t{0x01}` or `uint16_t{0x0102}`, never with literal arguments. So main could not deduce `T` and left the template uninstantiated. ValueFlow then bailed out on the generic body because of the incomplete variable `T`. With the PR, `T` is deduced from the argument ValueTypes, the template is instantiated with concrete types, and the generic declaration is removed. The bailout disappears because Cppcheck now analyses concrete instantiations instead of skipping the function. Confidence is medium because the deduced types (e.g. `int8_t` deduced as plain `char`) cannot be verified from this output." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/o/opencpn/opencpn_5.14.2+dfsg.orig.tar.xz", "your opencpn-5.14.2/libs/IXWebSocket/ixwebsocket/IXUniquePtr.h:16:60: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable args [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "regression", "confidence": "low", "explanation": "The PR adds a new valueFlowBailoutIncompleteVar debug message for `args` in the variadic `ix::make_unique` template, which main did not report. The function itself is unchanged code, so the new bailout most likely comes from the PR's changes to template handling. Candidates are the deferred removal of template declarations, the incremental symbol database update, or moving incomplete-variable detection into `finalize()`. In any of these cases `args` is left as an incomplete variable and ValueFlow skips the function. A new bailout means Cppcheck now understands this code worse; the exact cause cannot be confirmed from the output alone." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/p/paraview/paraview_6.1.1+dfsg1.orig.tar.gz", "main Utilities/VisItBridge/Library/VisItLib/common/state/Variant.C:104:38: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable T [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "improvement", "confidence": "high", "explanation": "DecodeFromString is a function template that was never instantiated in main. Its callers pass variables, not literals, so main left the template body unsimplified and ValueFlow bailed out on the incomplete 'T' in sizeof(T). The PR deduces template arguments from variable types, so the template is now instantiated (e.g. for float/double). The new invalidPointerCast warnings at line 98 confirm this. The bailout disappears because Cppcheck now understands the code better." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/p/paraview/paraview_6.1.1+dfsg1.orig.tar.gz", "main Utilities/VisItBridge/Library/VisItLib/common/state/Variant.C:59:38: debug: valueFlowConditionExpressions bailout: Skipping function due to incomplete variable T [valueFlowBailoutIncompleteVar]" ], "verdict": { "verdict": "improvement", "confidence": "high", "explanation": "EncodeToString is a function template called with variables (e.g. float/double values). Main could not deduce T from non-literal arguments, so the template was never instantiated. The uninstantiated body contained 'sizeof(T)' with T unknown, which produced the valueFlowBailoutIncompleteVar debug message. With the PR, type deduction from argument ValueTypes instantiates EncodeToString, , etc. The template body is removed, so the bailout disappears. The new invalidPointerCast warnings at line 55 for float*/double* confirm that the instantiations now exist. Cppcheck understands the code better, so removing this debug message is an improvement." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/p/primecount/primecount_8.8+ds.orig.tar.xz", "your primecount-8.8+ds/src/S1.cpp:82:11: debug: Failed to instantiate template \"S1_thread\". The checking continues anyway. [templateInstantiation]" ], "verdict": { "verdict": "neutral", "confidence": "low", "explanation": "The new type deduction now deduces `S1_OpenMP(x, (uint32_t) y, c, threads)` and instantiates `S1_OpenMP`, so its body is analyzed with concrete types. That is progress. Inside it, `S1_thread<1>(x, y, b, c, (X) primes[b], primes)` gives the non-type parameter `MU` explicitly and leaves the type parameters to be deduced. The simplifier cannot handle that mix, so it reports this debug message. `S1_thread` was not instantiated before either; main just never reached this call in an instantiated context. Cppcheck's understanding of the code did not get worse: the message only exposes an existing limitation on newly reached code. The PR suppresses exactly this kind of message for its own `lib/calculate.h`, which suggests the author treats it as an accepted limitation. Users see a new debug line but no change in analysis quality for `S1_thread`." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/p/pugixml/pugixml_1.16.orig.tar.gz", "your pugixml-1.16/src/pugixml.cpp:4500:144: style: Parameter 'alloc' can be declared as pointer to const [constParameterPointer]" ], "verdict": { "verdict": "improvement", "confidence": "high", "explanation": "The PR's new type deduction instantiates `node_copy_string` from the variable arguments at lines 4524/4525/4533/4534. Before, the template body was never instantiated, so it was not checked. The new warning is correct. `alloc` has the concrete, non-template type `xml_allocator*` and is only used in the null test `if (alloc && ...)`. It is never dereferenced or passed on as non-const, so it can be declared `const xml_allocator*` in every instantiation. The callers pass `xml_allocator*`, which converts implicitly. This is a new true positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/q/qt6-pim/qt6-pim_6.12.0~beta1+dfsg.orig.tar.xz", "your qt6-pim-6.12.0~beta1/src/versit/qversitreader_p.cpp:1144:91: style:inconclusive: Function 'containsAt < LByteArray >' argument 2 names different: declaration 'ba' definition 'match'. [funcArgNamesDifferent]\n qt6-pim-6.12.0~beta1/src/versit/qversitreader_p.h:241:80: note: Function 'containsAt < LByteArray >' argument 2 names different: declaration 'ba' definition 'match'.\n qt6-pim-6.12.0~beta1/src/versit/qversitreader_p.cpp:1144:91: note: Function 'containsAt < LByteArray >' argument 2 names different: declaration 'ba' definition 'match'." ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "Both runs report the same true positive at the same location. The template `containsAt` is declared in the header with parameter name `ba`, while the definition at line 1144 uses `match`. With the PR, Cppcheck deduces `T = LByteArray` from a call argument and instantiates the template, so the message now names the instantiation `containsAt < LByteArray >` instead of `containsAt`. The finding itself is unchanged. The name is marginally less clean because it shows template arguments that are not in the source, but it still identifies the function correctly. This is effectively a rewording, not a gained or lost diagnostic." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/q/qtwebkit-opensource-src/qtwebkit-opensource-src_5.212.0~alpha4.orig.tar.xz", "your qtwebkit-5.212.0-alpha4/Source/JavaScriptCore/profiler/ProfileNode.h:152:88: style: Parameter 'functor' can be declared as reference to const [constParameterReference]" ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "The PR now deduces and instantiates forEachNodePostorder. The body calls functor(currentNode), and CalculateProfileSubtreeDataFunctor::operator() is non-const because it modifies m_data. Declaring the parameter as a const reference would therefore not compile. The parameter is also the template type Functor&, so changing it would affect every instantiation. This new constParameterReference warning is a false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/q/qtwebkit-opensource-src/qtwebkit-opensource-src_5.212.0~alpha4.orig.tar.xz", "your qtwebkit-5.212.0-alpha4/Source/bmalloc/bmalloc/Algorithm.h:51:65: debug: Function::addArguments found argument 'mask < unsigned long >' with varid 0. [varid0]" ], "verdict": { "verdict": "regression", "confidence": "high", "explanation": "The new type deduction instantiates `mask(reinterpret_cast(x), ...)` as `mask`. In the instantiated declaration the parameter named `mask` (which has the same name as the function) is replaced by the instantiated name, so `Function::addArguments` sees an argument token `mask < unsigned long >` with varid 0. The new varid0 debug message shows that Cppcheck now models this code incorrectly: the parameter was wrongly renamed to the template instance name. The shadowFunction warning that main reported was a true positive (the parameter `mask` does shadow the function `mask`), and it has disappeared for the same reason." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/r/rocm-compilersupport/rocm-compilersupport_6.0+git20231212.4510c28+dfsg.orig.tar.xz", "your rocm-compilersupport-6.0+git20231212.4510c28+dfsg/lib/comgr/src/comgr.h:65:1: debug: SymbolDatabase couldn't resolve all user defined types. [debug]" ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "`TargetIdentifier` is an ordinary non-template struct whose members have LLVM types. Main resolved the user-defined types here without complaint. With the PR, a new 'SymbolDatabase couldn't resolve all user defined types' debug message appears at this struct. The likely cause is the new type-deduction rounds, which rebuild the symbol database or update it incrementally (scopes, types and type pointers). The type information for this struct apparently ends up less complete than before. The code itself has nothing new to resolve, so this new debug message means Cppcheck now models this code worse." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/r/rrootage/rrootage_0.23a.orig.tar.gz", "main rrootage-0.23a/src/bulletml/ygg/ygg_test.cpp:50:53: warning: Potentially invalid type conversion in old-style C cast, clarify/fix with C++ cast [dangerousTypeCast]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "Line 50 is `template T & vitalize(const T &X) { return (T&)X; }`. The cast only removes const; source and target have the same type T, so there is no type conversion. In main the template was never instantiated, because the call `vitalize(error_print())` has a non-literal argument. With T unknown, the cast looked like a conversion between unrelated types and dangerousTypeCast fired. The PR deduces T = error_print from the argument type and instantiates the template. The cast then converts const error_print& to error_print&, which has the same type scope, so the check no longer warns. The removed warning was a false positive caused by not understanding the template." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/s/synfig/synfig_1.5.5+dfsg.orig.tar.xz", "main synfig-1.5.5/synfig-core/src/synfig/matrix.cpp:202:24: debug: CheckClass::isMemberVar found used member variable 'm22' with varid 0 [varid0]" ], "verdict": { "verdict": "unclear", "confidence": "low", "explanation": "The removed message is a varid0 debug message: the use of member `m22` inside the `approximate_equal(m22, rhs.m22)` call in `Matrix3::operator==` had no variable id in main. With the PR, the call is likely rewritten through type deduction to `approximate_equal(...)`, and `setVarId` runs again (incrementally or as a full rebuild). That pass could give these member tokens a correct id, which would be a real fix. It could also give them a fresh id that is not tied to the member declaration, which would only hide the symptom; the members may sit in an anonymous struct or union. The output does not show which happened, so I cannot tell whether Cppcheck now understands the code better." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz", "main synfig-1.5.5/synfig-core/src/synfig/matrix.cpp:195:24: debug: CheckClass::isMemberVar found used member variable 'm01' with varid 0 [varid0]" ], "verdict": { "verdict": "improvement", "confidence": "low", "explanation": "In main, Cppcheck emitted a `varid0` debug message for `m01` in `Matrix3::operator==`. This means it saw a member access without a variable id, which is an internal gap in its understanding of the code. The PR deduces template arguments for calls like `approximate_equal(m01, rhs.m01)` and then re-runs `setVarId`. That rerun gives ids to tokens that lacked one, so `m01` now appears to get one and the debug message is gone. No new warnings appear for this code, so the change looks like a loss of internal noise and better token information. It is not fully certain that the new varid links back to the real member declaration, hence low confidence." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz", "main synfig-1.5.5/synfig-core/src/synfig/matrix.cpp:198:24: debug: CheckClass::isMemberVar found used member variable 'm11' with varid 0 [varid0]" ], "verdict": { "verdict": "improvement", "confidence": "low", "explanation": "In main, Cppcheck flagged member variables m01..m22 in `Matrix3::operator==` as used members with varid 0. That debug message means the members were never given variable ids, a gap in Cppcheck's understanding of the code. With the PR, the `approximate_equal(m11, rhs.m11)` calls are likely deduced and instantiated from the argument types. Afterwards the token data is updated again, and the incremental setVarId assigns ids to name tokens that had none, so the m11 tokens now probably get a real varid and the message disappears. Losing a varid0 debug message usually means better understanding. However, the id may come from a side effect of the incremental varid pass rather than proper member resolution, and the class definition is not shown. Confidence is therefore low." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz", "main synfig-1.5.5/synfig-core/src/synfig/matrix.cpp:199:24: debug: CheckClass::isMemberVar found used member variable 'm12' with varid 0 [varid0]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "Only the calls joined by `&&` lose the varid (line 194, after `return`, is not reported), so `) && approximate_equal ( m12 , ...` was likely misread as a declaration. The PR now deduces the template argument from the call, turning it into `approximate_equal(m12, rhs.m12)` with the symbols rebuilt afterwards. `m12` is a real `Matrix3` member, so the varid0 debug message marked a tokenizer defect. Its disappearance most likely means the member now gets a proper varid. Medium confidence because the exact cause is inferred, not verified." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz", "main synfig-1.5.5/synfig-core/src/synfig/matrix.cpp:200:24: debug: CheckClass::isMemberVar found used member variable 'm20' with varid 0 [varid0]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "Line 200 compares the member `m20` with `rhs.m20` through `approximate_equal(...)`, which is very likely a function template called without explicit template arguments. In main, Cppcheck left `m20` (and several sibling members) without a variable id, so the `varid0` debug message shows it did not fully understand the code. With the PR, the template arguments can be deduced from the argument types (members of type value_type) and the call is instantiated. The token data is then rebuilt and the member gets a proper varid. The message disappearing means Cppcheck now understands this code better." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz", "main synfig-1.5.5/synfig-core/src/synfig/matrix.cpp:202:24: debug: CheckClass::isMemberVar found used member variable 'm22' with varid 0 [varid0]" ], "verdict": { "verdict": "improvement", "confidence": "low", "explanation": "Line 202 compares the class members `m22` and `rhs.m22` inside `Matrix3::operator==`. Both are plain member variables, so they should have variable ids. Main emitted a varid0 debug message, which means it failed to give the member token a variable id. With the PR, the `approximate_equal(m22, rhs.m22)` calls are likely deduced and instantiated, followed by an extra `setVarId` pass. That pass gives ids to tokens that had none, which plausibly explains why the message is gone and suggests Cppcheck now understands the code better. The diff does not let me rule out that the check simply stopped visiting this scope, so confidence is low." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/v/voro++/voro++_0.5+revert-to-0.4.6+dfsg1.orig.tar.gz", "your voro++-0.4.6/src/container.hh:681:15: style:inconclusive: Technically the member function 'voro::container_poly::compute_cell < voro :: voronoicell , voro :: c_loop_all >' can be const. [functionConst]\n voro++-0.4.6/src/container.hh:681:15: note: Technically the member function 'voro::container_poly::compute_cell < voro :: voronoicell , voro :: c_loop_all >' can be const.\n voro++-0.4.6/src/container.hh:681:15: note: Technically the member function 'voro::container_poly::compute_cell < voro :: voronoicell , voro :: c_loop_all >' can be const." ], "verdict": { "verdict": "regression", "confidence": "medium", "explanation": "The PR's new type deduction now instantiates `compute_cell` from the call in `print_custom`, and this new functionConst warning comes from that instantiation. The body calls `vc.compute_cell(...)`. `vc` is a `voro_compute` object held by value as a member, and its `compute_cell` is a non-const member function template that changes internal state (mask/counter buffers). So declaring `container_poly::compute_cell` const would not compile. Cppcheck likely cannot resolve the call into the uninstantiated `voro_compute` template, so it wrongly treats the method as const-able. The note line is also duplicated. This is a new false positive." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/v/vtk6/vtk6_6.3.0+dfsg2.orig.tar.gz", "your vtk6-6.3.0+dfsg2/Common/Core/Testing/Cxx/TestCxxFeatures.cxx:170:18: style: Condition 'should_be_0!=0' is always false [knownConditionTrueFalse]\n vtk6-6.3.0+dfsg2/Common/Core/Testing/Cxx/TestCxxFeatures.cxx:169:45: note: Calling function 'FullySpecializedFunction < float >' returns 0\n vtk6-6.3.0+dfsg2/Common/Core/Testing/Cxx/TestCxxFeatures.cxx:169:45: note: Assignment 'should_be_0=FullySpecializedFunction < float >(static_cast(0))', assigned value is 0\n vtk6-6.3.0+dfsg2/Common/Core/Testing/Cxx/TestCxxFeatures.cxx:170:18: note: Condition 'should_be_0!=0' is always false" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "With the PR, Cppcheck deduces T=float for the call `FullySpecializedFunction(static_cast(0))`: the argument is `float*` and the parameter has the form `T*`. That is the correct C++ deduction. The primary template it instantiates always returns 0, so `should_be_0 != 0` really is always false. Before the PR the call was not instantiated, so Cppcheck could not see this. The code is a compiler-feature self-test, but the warning is still factually correct and follows the usual knownConditionTrueFalse behaviour for known return values. This is a true positive gained through better template type deduction." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/v/vtk6/vtk6_6.3.0+dfsg2.orig.tar.gz", "your vtk6-6.3.0+dfsg2/Filters/SMP/vtkThreadedSynchronizedTemplatesCutter3D.cxx:183:11: style: Variable 'values' can be declared as pointer to const [constVariablePointer]" ], "verdict": { "verdict": "improvement", "confidence": "medium", "explanation": "ContourImage is a function template that is only called with deduced arguments, such as ContourImage(self, exExt, data, output, ptr, ...) with a typed pointer. Main never instantiated it, so the body was not checked. The PR deduces T from the argument types and instantiates the template, so the body is now analyzed. 'values' is set from self->GetValues(). In this synchronized-templates code it is normally only read (value = values[vidx]), so 'can be declared as pointer to const' is very likely correct. The matching warnings for inExt, origin, spacing and tablePtr in the non-SMP cutter point the same way. The rest of the function body is not shown, which is why confidence is medium." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/y/yuzu/yuzu_0-1734+ds.orig.tar.gz", "your yuzu-0-1734+ds/src/frontend_common/config.h:191:31: style: The member function 'Config::ToString < bool >' can be static. [functionStatic]\n yuzu-0-1734+ds/src/frontend_common/config.h:191:31: note: The member function 'Config::ToString < bool >' can be static.\n yuzu-0-1734+ds/src/frontend_common/config.h:191:31: note: The member function 'Config::ToString < bool >' can be static." ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "`ToString` is a member function template that uses no members of `Config`, so 'can be static' is a true positive. Main reported it once, against the uninstantiated template ('Config::ToString').\n\nWith the PR, the new type deduction instantiates `ToString` for each deduced argument type (bool, double, int, unsigned long). The check now runs on each instantiation and reports the same issue at the same line once per type. This entry, for `ToString`, is one of those.\n\nThe finding is still correct and points to the same code and the same fix. Only its form changed: one message became several near-duplicates naming instantiations. That is slightly noisier but neither adds nor loses a real finding, so the net effect for users is about neutral." } }, { "key": [ "https://ftp.debian.org/debian/pool/main/y/yuzu/yuzu_0-1734+ds.orig.tar.gz", "your yuzu-0-1734+ds/src/frontend_common/config.h:191:31: style: The member function 'Config::ToString < double >' can be static. [functionStatic]\n yuzu-0-1734+ds/src/frontend_common/config.h:191:31: note: The member function 'Config::ToString < double >' can be static.\n yuzu-0-1734+ds/src/frontend_common/config.h:191:31: note: The member function 'Config::ToString < double >' can be static." ], "verdict": { "verdict": "neutral", "confidence": "medium", "explanation": "`Config::ToString` never uses `this`; it only works on `value_` and `std::to_string`. So 'can be static' is a true positive for the template and for any instantiation, including `double`. Main already reported this at the same line for the uninstantiated template ('Config::ToString'). Now that the template is instantiated through type deduction, the same finding is reported once per instantiation (`bool`, `double`, `int`, `unsigned long`). This entry is not a new finding and not a false positive. It is the same correct warning with the instantiation name added, alongside some duplicate noise at one location. Net effect for users is roughly neutral." } } ], "started": "2026-10-11 02:33:21 UTC", "runner": "server" }