On 20/09/2020 13:32, Caolán McNamara wrote:
On Tue, 2020-09-08 at 15:45 +0200, Stephan Bergmann wrote:
On 08/09/2020 11:13, scan-admin@xxxxxxxxxxxx wrote:
CID 1466649: Parse warnings (PARSE_ERROR)
class template name must be a placeholder for the
complete type being initialized (not for a component of that
type)
25 const OStringLiteral sGlobal("::");
I have contacted Coverity about the above PARSE_ERROR problem.
I notice that while global "const OStringLiteral" and "const
OUStringLiteral" give PARSE_ERROR that non-const global
"OStringLiteral" and "OUStringLiteral" do not
Lets see whether <https://gerrit.libreoffice.org/c/core/+/103085> "Make
some OUStringLiteral vars constexpr" would similarly get rid of those
unhelpful error messages.
(By the way,
Some recent change in the LibreOffice source code caused Scan to fail with
Unrecoverable parse warning (PARSE_ERROR)
1. modified_class_template_placeholder: class template name must be a placeholder for the complete type being initialized (not for a component of that type)
in four places:
* <https://scan5.coverity.com/reports.htm#v21415/p10276/fileInstanceId=177121618&defectInstanceId=49435912&mergedDefectId=1466649>
* <https://scan5.coverity.com/reports.htm#v21415/p10276/fileInstanceId=177142821&defectInstanceId=49436462&mergedDefectId=1466650>
* <https://scan5.coverity.com/reports.htm#v21415/p10276/fileInstanceId=177142821&defectInstanceId=49436223&mergedDefectId=1466653>
* <https://scan5.coverity.com/reports.htm#v21415/p10276/fileInstanceId=177147752&defectInstanceId=49436412&mergedDefectId=1466661>
That OStringLiteral is a class template, see <https://git.libreoffice.org/core/+/4b9e440c51be3e40326bc90c33ae69885bfb51e4/include/rtl/string.hxx#80>, and these four global variable definitions rely on class template argument deduction. There are similar definitions of static variables in function bodies, see <https://git.libreoffice.org/core/+/4b9e440c51be3e40326bc90c33ae69885bfb51e4/desktop/source/lib/init.cxx#4886>, for which Scan did not report errors.
Any chance to get this fixed in Scan, or some workaround/annotation that can be applied to the code? Many more instances of this pattern are scheduled to hit the LibreOffice code base soon, and I would like to get this issue sorted out first.
is what I had sent to <scan-admin@xxxxxxxxxxxx>, but without any
response. And then I completely forgot about this issue when submitting
<https://git.libreoffice.org/core/+/e6dfaf9f44f9939abc338c83b3024108431d0f69%5E!/>
"Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString",
which caused many more of those errors now.)
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
