summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/compat.hxx
AgeCommit message (Collapse)Author
2020-09-04tdf#124176 Use #pragma once in compilerpluginsGeorge Bateman
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: Id60579406a5aa16c3dc05a1bb5f1c1c828d39c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100251 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-02<http://reviews.llvm.org/D22128> has been fixed since LLVM 5Stephan Bergmann
...so compat::getSubExprAsWritten is now only needed for the ConstantExpr issue that cannot hit for LLVM < 8 (see TODO "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String") Change-Id: I12ad4624d353b1d801136e9988b261290e2f94d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101905 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02Turn OStringLiteral into a consteval'ed, static-refcound rtl_StringStephan Bergmann
...from which an OString can cheaply be instantiated. The one downside is that OStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a containers that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::string_view, without loss of efficiency compared to the original OStringLiteral, and without loss of expressivity (esp. with the newly introduced OString(std::string_view) ctor). The new OStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OStringLiteral is in all cases where an object that shall itself not be an OString (e.g., because it shall be a global static variable for which the OString ctor/dtor would be detrimental at library load/unload) must be converted to an OString instance in at least one place. Other string literal abstractions could use std::string_view (or just plain char const[N]), but interestingly OStringLiteral might be more efficient than constexpr std::string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". Those places, as well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been replaced with OString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). This change also revealed a bug in at least recent Clang 12 trunk CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least in some calls from loplugin code (for which it can be fixed for now in the existing compat::getSubStringAsWritten). A similar commit for OUStringLiteral is planned, too. Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-04loplugin:simplifybool a little more aggressiveNoel Grandin
with expressions like !(a && b) Change-Id: Id2acec2a8d0eaaa8e5e37dbd2cae7281be36572e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03Revert "Adapt to changed clang::ASTContext::getParents behavior on Clang 11 ↵Stephan Bergmann
trunk" This reverts commit 09aa5a9be8b9b3c88cf25b85e0eda28c5ef19aa4, now that <https://github.com/llvm/llvm-project/commit/ 551092bc3dfb86f1e11a55f3bee0c8ee1be6fdd6> "Revert AST Matchers default to AsIs mode" reverted the Clang commit that prompted this compilerplugins change. Change-Id: I75c8b4cb2894cd67a791db460f2886a783856c73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100026 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-28Adapt to Clang 12 trunk Expr::getIntegerConstantExpressionStephan Bergmann
<https://github.com/llvm/llvm-project/commit/ 36036aa70ec1df7b51b5d30b2dd8090ad2b6e783> "Reapply 'Rename/refactor isIntegerConstantExpression to getIntegerConstantExpression'" Change-Id: I99277601fe7ffa3e0e5d22a4b3aaca4f51551ab3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99570 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-25Adapt to changed clang::ASTContext::getParents behavior on Clang 11 trunkStephan Bergmann
...since <https://github.com/llvm/llvm-project/commit/ d0da5d2bbe8305d06dc01a98706fd73e11e24a9f> "Change default traversal in AST Matchers to ignore invisible nodes". This caused failures > [CPT] compilerplugins/clang/test/constparams.cxx > ParmVarDecl 0x11d76c730 <compilerplugins/clang/test/constparams.cxx:15:12, col:18> col:18 used f1 'int *' > DeclRefExpr 0x11d76c948 'int *' lvalue ParmVar 0x11d76c730 'f1' 'int *' > ParmVarDecl 0x11d76cc80 <compilerplugins/clang/test/constparams.cxx:21:12, col:18> col:18 used f2 'int *' > DeclRefExpr 0x11d76ce60 'int *' lvalue ParmVar 0x11d76cc80 'f2' 'int *' > error: 'error' diagnostics expected but not seen: > File compilerplugins/clang/test/constparams.cxx Line 15: this parameter can be const Class1::Class1 [loplugin:constparams] > error: 'error' diagnostics seen but not expected: > File compilerplugins/clang/test/constparams.cxx Line 15: no parent? [loplugin:constparams] > File compilerplugins/clang/test/constparams.cxx Line 21: no parent? [loplugin:constparams] > 3 errors generated. [...] > [CPT] compilerplugins/clang/test/unusedenumconstants.cxx > error: 'error' diagnostics expected but not seen: > File compilerplugins/clang/test/unusedenumconstants.cxx Line 30: read Bottom [loplugin:unusedenumconstants] > error: 'error' diagnostics seen but not expected: > File compilerplugins/clang/test/unusedenumconstants.cxx Line 30: write Bottom [loplugin:unusedenumconstants] > 2 errors generated. [...] > [CPT] compilerplugins/clang/test/unusedfields.cxx > error: 'error' diagnostics expected but not seen: > File compilerplugins/clang/test/unusedfields.cxx Line 156 (directive at compilerplugins/clang/test/unusedfields.cxx:164): write m_f5 [loplugin:unusedfields] > File compilerplugins/clang/test/unusedfields.cxx Line 210 (directive at compilerplugins/clang/test/unusedfields.cxx:211): read m_f1 [loplugin:unusedfields] > 2 errors generated. For compilerplugins/clang/test/constparams.cxx at least it would have worked to fix that locally with > diff --git a/compilerplugins/clang/constparams.cxx b/compilerplugins/clang/constparams.cxx > index 95c8184009d7..70f056fa5a69 100644 > --- a/compilerplugins/clang/constparams.cxx > +++ b/compilerplugins/clang/constparams.cxx > @@ -274,7 +274,7 @@ bool ConstParams::checkIfCanBeConst(const Stmt* stmt, const ParmVarDecl* parmVar > { > for ( auto cxxCtorInitializer : cxxConstructorDecl->inits()) > { > - if ( cxxCtorInitializer->getInit() == stmt) > + if ( cxxCtorInitializer->getInit()->IgnoreImpCasts() == stmt) > { > if (cxxCtorInitializer->isAnyMemberInitializer()) > { (somewhat unintuitively, given the Clang change is apparently about ignoring more implicit nodes), but overall it appears better---at least for now---to use a getParents variant that keeps the old traversal behavior. For that, instead of using the clang::ASTContext::ParentMapCtx, we create our own loplugin::Plugin::parentMapContext_. There appear to be no uses of ASTContext::getParent across the Clang codebase itself, outside of ASTMatcher code, so it looks unlikely that creating our own ParentMapContext instance would degrade performance by no longer sharing cached data between Clang's internals and our plugin. (And given that ASTContext::getParents is deprecated with the note "New callers should use ParentMapContext::getParents() directly", this may well be the correct way in the long run, anyway.) Change-Id: I46c7912f2737e7c224fd45ab41441f69e2f10bd4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94795 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-26Adapt to clang::MaterializeTemporaryExpr::GetTemparyExpr renameStephan Bergmann
...in <https://github.com/llvm/llvm-project/commit/ b0561b3346e7bf0ae974995ca95b917eebde18e1> "[NFC] Refactor representation of materialized temporaries" Change-Id: I02fbf6765f9713e4d457f07521129cc9d8db5751 Reviewed-on: https://gerrit.libreoffice.org/83669 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14New loplugin:getstrStephan Bergmann
...to find matches of ... << s.getStr() (for the rtl string classes) that can be written as just ... << s Some notes: * The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in desktop/source/app/crashreport.cxx (even though that would also be done internally by the "<< OUString" operator) to clarify that these values are written out as UTF-8 (and not as what that operator << happens to use, which just also happens to be UTF-8). * OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now. * Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx. * The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just go, too. Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136 Reviewed-on: https://gerrit.libreoffice.org/80762 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-10Fix detection of std::unique_ptr/shared_ptr in loplugin:redundantpointeropsStephan Bergmann
...when the get member function is implemented in a base class, as happens for std::shared_ptr in libstdc++ (where it is implemented in base __shared_ptr; see also 7d361e96c9ea822790db21806e9fc05279423833 "loplugin:redundantpointerops"). And while at it, check for precisely the classes we are interested in (for which we know the semantics of get and operator*), rather than any classes whose unqualified names happen to match. Change-Id: I0c85ba46f191a2ee038c8175d979aa0c1be765cd Reviewed-on: https://gerrit.libreoffice.org/80585 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-09Improve loplugin:redundantpointerops diagnostic messagesStephan Bergmann
Change-Id: If09f5c916f2db98c5d1754d2fbc8f53c502799c9 Reviewed-on: https://gerrit.libreoffice.org/80543 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it)Stephan Bergmann
Change-Id: I8f83c1941b8f39b261005939f4dcf3577ae9fc6f Reviewed-on: https://gerrit.libreoffice.org/76702 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-05-27fix clang version checkLuboš Luňák
As 56f87dac69b4 says, this is about clang 9, not clang 8. Change-Id: I2978d2235c7eb3ad438082f7b08a1bd68977ed6f Reviewed-on: https://gerrit.libreoffice.org/72974 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-05-16Adapt compilerplugins to Clang 9 isExplicitSpecified -> getExplicitSpecifierStephan Bergmann
see <https://github.com/llvm/llvm-project/commit/ 76b9027f352a83c13c98820724071c5e3bea6232> "[c++20] Add support for explicit(bool), as described in P0892R2." Change-Id: Ia8a6902a64ab3377328fd5e3ed57246d214176f2 Reviewed-on: https://gerrit.libreoffice.org/72335 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-29Revert "comment out the EvaluateAsInt compat code for now"Stephan Bergmann
This reverts commit da9fb5d6d9ebf9363981c370ce937d8848989fcb, obsoleted by <http://llvm.org/viewvc/llvm-project?view=revision&revision=347756> "Re-commit r347417 'Re-Reinstate 347294 with a fix for the failures.'"
2018-11-29comment out the EvaluateAsInt compat code for nowNoel Grandin
sberg: Note how that Clang change keeps getting reverted; latest one is <http://llvm.org/viewvc/llvm-project?view=revision&revision=347656> "Revert r347417 'Re-Reinstate 347294 with a fix for the failures.'" But lets wait a little while to see how things settle there. Change-Id: I05b34ca1377792bcb4c557defd3e9b5d11ee2b14 Reviewed-on: https://gerrit.libreoffice.org/64168 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-27add EvaluateAsInt compat function for latest clangNoel Grandin
the old EvaluateAsInt method has been dropped as from current clang Change-Id: Ie30d1547ad8de777badff4b380d2fc9fb261e8fe Reviewed-on: https://gerrit.libreoffice.org/64107 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-23Bump compiler plugins Clang baseline to 5.0.2Stephan Bergmann
...as discussed at <https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html> "minutes of ESC call ..." Change-Id: Ia053da171d59747984546f38e19da808825b4f79 Reviewed-on: https://gerrit.libreoffice.org/63832 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-10Fix failure of loplugin:useuniqueptr with older compilersStephan Bergmann
...where CompilerTest_compilerplugins_clang failed in compilerplugins/clang/test/useuniqueptr.cxx due to Foo24's HTMLAttrs::const_iterator it = m_aSetAttrTab.begin(); and either the old compiler lacked Clang's recent <https://reviews.llvm.org/D50666> "Fix Stmt::ignoreImplicit" (and the above initialization expression happens to include a CXXBindTemporaryExpr, at least with libstdc++), or an even older compiler was used in pre-C++17 mode, so the above initialization expression happens to include an elidable CXXConstructExpr copy constructor call. Change-Id: I757a9ad76829e399b4fe2da1c82863909b8c9657 Reviewed-on: https://gerrit.libreoffice.org/61531 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-10Avoid -Werror=deprecated-declarations with recent Clang trunkStephan Bergmann
...which first added alternative names to and then deprecated getLocBegin/End Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2 Reviewed-on: https://gerrit.libreoffice.org/58820 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-05-04Adapt to Clang trunk SourceManager::getImmediateExpansionRange changesStephan Bergmann
...of <http://llvm.org/viewvc/llvm-project?view=revision&revision=331155> "PR37189 Fix incorrect end source location and spelling for a split '>>' token", changing (among others) the return type of getImmediateExpansionRange from a std::pair of token locations to CharSourceRange (which will typically also represent token locations, but might also represent char locations). For now, map the return value of getImmediateExpansionRange back to a std::pair (as expected by our compilerplugins code in its current form), and mark the char location case with a TODO (which will need to be addressed if any of our plugins starts to produce wrong results due to not handling that char location case). In the long run, we should instead adapt our code to use the new return type of getImmediateExpansionRange directly. Change-Id: Idc2f5dc43830af4798b55bf605976c4ab146c522 Reviewed-on: https://gerrit.libreoffice.org/53817 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-19Bump --enable-compiler-plugins to Clang 3.8.0Stephan Bergmann
<https://lists.freedesktop.org/archives/libreoffice/2017-December/079107.html> "Clang baseline bump" Change-Id: I18fca8794ea34118fc6308458064d0c28cf5caf7 Reviewed-on: https://gerrit.libreoffice.org/46557 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-10Fix isSalCallFunction furtherStephan Bergmann
...after a31267be1bb42e8a5f80a3b660bbf969eeb5b647 "Fix isSalCallFunction so it also works on Windows", so that it actually does work on Windows. Change-Id: I0218fb41b3e1000e2325967a18dfaafaa95fe415 Reviewed-on: https://gerrit.libreoffice.org/46193 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-10-24loplugin:includeformStephan Bergmann
Consistently use the #include "..." form for exactly those cases where the included file is located next to the including file, see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-October/078601.html> "C[++]: Normalizing include syntax ("" vs <>)". (For UNO API include files, see 189abcf0db61c41a565bd355294bf6e712fc3e5a "loplugin:includeform: UNO API include files".) (Some of the commits done earlier with messages containing "Change done in preparation of loplugin:includeform" etc. were based on a somewhat different earlier version of this plugin and would not be necessary with the current form. But they are harmless and reverting them would probably cause more noise than benefit, so just leave them in.) Change-Id: I9fe9268ed84d31b5df71857a2e535972b11254ce Reviewed-on: https://gerrit.libreoffice.org/43730 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-07-17Fix typosAndrea Gelmini
Change-Id: I9d2c641b485c32ddccf0bfaaed1d0796572d1d33 Reviewed-on: https://gerrit.libreoffice.org/39477 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2017-07-03loplugin:casttovoidStephan Bergmann
Change-Id: I427b15b35ef6e7c803cb8a00c961d35175ae8cb2
2017-05-19...and re-eanble loplugin:stringcopy againStephan Bergmann
<http://reviews.llvm.org/D22128> "Make CastExpr::getSubExprAsWritten look through implicit temporary under CK_ConstructorConversion" was biting me again. (I had originally developed loplugin:stringcopy against a Clang build that includes my local fix for that issue. I really need to see to get that resolved upstream...) (And while 957874168491f4b030fda85c65dd969aae82a670 "loplugin:stringcopy" was actually a false positive, it doesn't hurt either, so just keep it.) Change-Id: I726956adfbe67681005173cfdfed2e4b4cd6253d
2016-11-25Clean up PPCallbacks compatiblity fixStephan Bergmann
Change-Id: I91f1db18b7876c4ecc30f7f97283e0ef0369eba5
2016-06-29Remove support for Clang < 3.4Stephan Bergmann
Change-Id: I81e97c5f720535b33dd3ce72d01151765e4e93a0
2016-06-29Remove support for Clang < 3.3Stephan Bergmann
Change-Id: I185852a738bac10dc6d331afccfcbc7ae1225cb1
2016-06-28Adapt to Clang 3.4 (in preparation of a buildbot on CentOS 7)Stephan Bergmann
Change-Id: Ie2859f03b31c57deb7fd0deba3285f782e33b239
2016-06-28loplugin compat with clang 3.4Noel Grandin
Change-Id: I264fe688519b8b2173d5cccd8a453847a7fb89d9
2016-06-24Adpat to <https://llvm.org/svn/llvm-project/cfe/trunk@273647>Stephan Bergmann
"Use more ArrayRefs" Change-Id: Ied0ab11dd9366b3f499100b2627f4919cca52c9c
2016-04-21typoStephan Bergmann
Change-Id: I67721e86073bd2f67bee3ffbbb81fd5d143997d8
2016-04-21Better fix for 13758a3d154e8e450fdfe8bcdeb6b3a03996c53aStephan Bergmann
"SourceManager::isMacroArgExpansion has only one param in older Clang", which caused false positives like warning about sal_False in CPPUNIT_ASSERT_EQUAL(guard.p->m1, sal_False); in cppu/qa/cppumaker/test_cppumaker.cxx Change-Id: I1c5a67527aef381e336d71cb8fefbb87961bbf96
2016-02-29compilerplugins: fix clang-3.7 buildMiklos Vajna
Change-Id: I2d845d3e008cec085ce2b355c9a058363bd021cb
2016-02-26These version checks are about the Clang the plugins are built /against/Stephan Bergmann
...not the (Clang) compiler they are being built /with/. (Also simplifies the checking #if code.) Change-Id: I416321be4ef4478785be40571f81500fd3b6feb8
2015-11-19isLookupContext already available in Clang 3.7.0Stephan Bergmann
Change-Id: Ia17a116b1f7605b5a8d572c6a6f4ef64adea8f94
2015-11-19Adapt compilerplugins to old Clang versionsStephan Bergmann
Change-Id: I91335f1e81e251f0578792517dded9fae239fb61
2015-11-06compilerplugins: getAsTagDecl doesn't exist in clang 3.5Michael Stahl
Change-Id: If7277820227486e2eb578a167e0fd9f05c8f74ae Reviewed-on: https://gerrit.libreoffice.org/19823 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2015-09-21tdf#94389 compilerplugins: clang 3.7.0Daniel Robertson
Fix errors that occur in build with clang 3.7.0 Change-Id: I0e8743f2b6a288d10b4e78e884ce34cfca4dd77c Reviewed-on: https://gerrit.libreoffice.org/18738 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2015-08-04-Werror,-Wunused-parameterStephan Bergmann
Change-Id: Iede9204bf93014e757c4fdf4a8363a90b7577dbc
2015-08-04fix crash in refcounting pluginNoel Grandin
introduced by commit c15b4cf39a74176cee64795129d76f411d2c0a69 "Adapt to current Clang trunk towards 3.7" Change-Id: I00f58d3bc79e641df9bba4e9b1d5c8463b87dc42
2015-08-04Adapt to current Clang trunk towards 3.7Stephan Bergmann
Change-Id: Ibb2c641d49a1773be789c9259f53a040db6f605f
2015-03-28Clean up isMacroBodyExpansionStephan Bergmann
Change-Id: I745b320dd5f44d54371d8a0b961c49793e3e0ad6
2015-03-27new clang plugin: staticmethodsNoel Grandin
Genius suggestion from Tor Lillqvist, write a clang plugin that finds methods that can be static. Change-Id: Ie6684cc95d088e8750b300a028b49f763da00345
2015-03-25new constantfunction lopluginNoel Grandin
Change-Id: Ie9b7a0c41fc4dbd2560ceff6bae9ab85357f518b
2015-02-26Adapt compilerplugins to Clang trunk towards 3.7Stephan Bergmann
Change-Id: I5b41039bf63a4c2f313fe7a57c0f6934dcb0752d
2015-01-08Fix typoTor Lillqvist
Change-Id: Ifdbcbcc51c29dc14b2a3b4c845481b45300313d6
2015-01-08loplugin:cstylecast: improve detection of C codeStephan Bergmann
Change-Id: Id5dd1ee1a29c4e1c7cb2b58419d6ccb1f032bffe
generated by cgit (git 2.34.1) at 2025-02-06 14:19:39 +0000