summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/sallogareas.cxx
AgeCommit message (Collapse)Author
2024-09-06drop unused eventtesting cmd line optionCaolán McNamara
Change-Id: I90edb80f3b414cbe0a81ecccbf1080106708a131 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172933 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2022-07-01Adapt to LLVM 15 trunk clang::StringLiteral::isAscii renameStephan Bergmann
<https://github.com/llvm/llvm-project/commit/a9a60f20e6cc80855864b8f559073bc31f34554b> "[Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]" Change-Id: Iac293c19bd135a94dcc3a3ef9f252ca6175c959a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136744 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-17Bump compiler plugins Clang baseline to 12.0.1Stephan Bergmann
...as discussed in the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2020-November/086234.html> "Bump --enable-compiler-plugins Clang baseline?" (and now picked up again at <https://lists.freedesktop.org/archives/libreoffice/2022-February/088459.html> "Re: Bump --enable-compiler-plugins Clang baseline?"), and clean up compilerplugins/clang/ accordingly Change-Id: I5e81c6fdcc363aeefd6227606225b526fdf7ac16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129989 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-02create common macro and method for logging unknown attributesNoel
instead of repeating the code everywhere Change-Id: Idb94054b392ed256e64259cdb17d1522bf3c52b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105184 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-29Adapt to "[ADT] Make StringRef's std::string conversion operator explicit"Stephan Bergmann
...<https://github.com/llvm/llvm-project/commit/ 777180a32b61070a10dd330b4f038bf24e916af1>. This is just a quick fix to get copmilerplugins buiding again with latest LLVM/Clang trunk. Ideally, we should get rid of as many of those (potentially expensive) conversions from llvm::StringRef to std::string as possible. Change-Id: I18e185e0022a06fd8e3b983a3c4f80e1f3b96746 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87682 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-16convert some plugins to LO_CLANG_SHARED_PLUGINSNoel Grandin
Change-Id: I06ccd31248f9671fc96dc3d0e7f3cf696ec07f28 Reviewed-on: https://gerrit.libreoffice.org/75686 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-16remove sallogareas header fileNoel Grandin
in preparation for using LO_CLANG_SHARED_PLUGINS Change-Id: I91cf186188bf0f15fc4e5adc095d404d89d0b025 Reviewed-on: https://gerrit.libreoffice.org/75681 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-14filter out some of the AST in the pluginsNoel Grandin
by checking if the current namespace decl is in our code, so we have to scan less stuff, which results in a 10% perf improvement for me Change-Id: Idf0e30d57b6d0dcd13daa9ed679c28b9d233d387 Reviewed-on: https://gerrit.libreoffice.org/58942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
2018-04-03pass area param to DBG_UNHANDLED_EXCEPTIONNoel Grandin
and update sallogareas plugin to enforce this Change-Id: Id0782c8a1f619372e10d931aec3c6a4743a4c86a Reviewed-on: https://gerrit.libreoffice.org/52249 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-04-02give DBG_UNHANDLED_EXCEPTION_WHEN an area parameterNoel Grandin
and rename it to DBG_UNHANDLED_EXCEPTION, to make it more like the SAL_WARN-type macros. Use some macro magic to deal with different numbers of arguments. Update the sallogareas plugin to check the area parameter of DBG_UNHANDLED_EXCEPTION. Change-Id: Ie790223244c3484f41acb3679c043fb9b438e7c4 Reviewed-on: https://gerrit.libreoffice.org/52073 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-20reformat some loplugin codeNoel Grandin
to match our more normal conventions. Also drop the 'using std' and some other cruft Change-Id: I02ef81c5427188bc03a20b157a57a900a9d7bf0d
2017-02-28Adapt loplugin:sallogareasStephan Bergmann
...to b6a69585b00867005820c1dd94e10e0e6b545e2a "old sal_detail_log_backtrace into sal_detail_log" and follow-up c697ae306cd4eaa8144ed93fc908e50d5934e249 "Some clean up" Change-Id: Ie38899e70c5b326724f9442fbf92e453b05eec01
2017-02-09Fix SAL_DEBUG_BACKTRACEStephan Bergmann
...after 56d071c10ca8016848f1f059aa3eb197fe928844 "rename SAL_DEBUG_TRACE to SAL_DEBUG_BACKTRACE" (looks like this doesn't get used much...)
2017-02-01loplugin: use TypeCheck instead of getQualifiedNameAsStringNoel Grandin
since the latter is rather slow Change-Id: Ib73cdb923585580777c2265b561c1808e93b2baa Reviewed-on: https://gerrit.libreoffice.org/33585 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-15disable the 'two different log areas in the same file' loplugin checkNoel Grandin
too many false+ to leave it alive by default Change-Id: I6d8f92b630c351c1ac788fad79f8d7c435ba4963
2016-12-15teach sallogareas plugin to catch inconsistenciesNoel Grandin
Change-Id: I8bcea5ffc74d48148bea78da8c17744e288c069a Reviewed-on: https://gerrit.libreoffice.org/32004 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-12-14Disambiguate clang::StringLiteralStephan Bergmann
...vs. recently introduced llvm::StringLiteral (llvm/ADT/StringRef.h) Change-Id: I4d74546b0d1401a74b0c15368bbc93794ecd0b1d
2016-04-27cppcheck: silence warnings in compilerpluginsJochen Nitschke
mostly missing explicit before ctors and uninitialized member vars one odd use of std::find > compilerplugins/clang/implicitboolconversion.cxx > 800 stlIfFind warning Suspicious condition. > The result of find() is an iterator, but it is not properly checked. Change-Id: Iade53494cd7fe8ddb0e110e431449ae5a517fe3b Reviewed-on: https://gerrit.libreoffice.org/24398 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-01-06Re-enable loplugin:sallogareasStephan Bergmann
I had it locally enabled for like a month now, and it did not produce any more noise than any of the other plugins, but quite some amount of malformed area designators had been introduced over time. Change-Id: I642591496bb9338246ba43a3d988481930c087fb
2014-09-11Deactivate the sallogareas pluginTor Lillqvist
It's boring and a waste of time to have to keep registering in include/sal/log-areas.dox new log areas that other people have introduced. We don't really have a uniform policy for logging anyway, so why bother trying to enforce a such for the log areas? Anybody uses whatever log areas and log output style and formatting they want in the code they happen to be working on. And that's fine with me. We were supposed to be the project that avoids unnecessary process, rules and bureaucracy, right? Change-Id: I6bddcb56b58edcd885e5dc743c8730878de0036d
2014-01-27Prepare dual-mode compiler plugin featureStephan Bergmann
...which can act as either a rewriter or a non-rewriter that emits warnings. Also added COMPILER_PLUGIN_WARNINGS_ONLY=X to demote warnings from plugin X from errors to warnings, even under --enable-werror. Change-Id: I05361936240a890515c6bba2459565417c1746b7
2013-09-22add mode lines to new files (and idls) since last runCaolán McNamara
Change-Id: Id1e74f18c90e69d1a781c8f02e30dc3c005ed4fd
2013-05-02add constLuboš Luňák
Change-Id: I71236b9ca6300372ba00c85401cf19f6c0e7ac99
2013-04-24Update location of log-areas.doxTor Lillqvist
Change-Id: If54a3d7047f13ae9c9345c21737a89afee645403
2013-03-28pass around CompilerInstance rather than ASTContextLuboš Luňák
It's possible to get the latter from the former, and the former is useful for other things too (access to the preprocessor, for example). Change-Id: I708d709129fd3a35bf7c63da4de09c2e696b382d
2013-02-02remove not needed #includeLuboš Luňák
Change-Id: I0fa791733407199db5be2cc9606ac9be1da64188
2013-02-02append [loplugin] automatically in report() rathen than manually everywhereLuboš Luňák
Change-Id: I2f98622f152ae0c7ac8d1113d6380f686ac7234c
2013-02-02move documentation of plugins to the .cxx filesLuboš Luňák
It's mostly there already anyway, no need to duplicate it. Change-Id: I5b066f90725a064fb0746e1411900e835e3f66c3
2013-02-02avoid having to manuall modify sources when adding a new clang pluginLuboš Luňák
Now each one registers in its .cxx file. Change-Id: I811c0d4400c2bdccc1c287269378d7e8ad8743ce
2013-01-06do not set our clang timestamp to the timestamp of the clang binaryLuboš Luňák
If the clang binary comes from a package which had been built before any of our clang related sources were changed the last time, the timestamp would be older and so there would be no rebuild. So do the stamp handling the usual way, clang upgrades will work fine, downgrades will not, but that's the same problem like with downgrading a library and its headers. To somewhat mitigate the problem (Clang plugin doesn't get cleaned by 'make clean'), include the full Clang version (which includes SVN revision) in config_clang.h and make all Clang plugin code include that, so at least configure re-run will trigger a rebuild if necessary. Change-Id: I993197f79e92e36105092c92c33b2e1db343e975
2012-12-26config_clang.hLubos Lunak
2012-12-05Adapt to Clang 3.2Stephan Bergmann
Change-Id: I9e51867198d7677c26cbd97f5d9c85ac13dc90c5
2012-10-26do not warn about missing area in SAL_DEBUGLuboš Luňák
Change-Id: I99314136cac7f47a5adf8e0e29093ec9fbf4fd90
2012-10-19only one warning per one SAL_INFO/SAL_WARNLubos Lunak
Change-Id: I5aafe9ed51c86dc31492d205f44fba6b1db137d2
2012-10-15support for compiler rewritersLuboš Luňák
Change-Id: I12e98ac9fc49ef2007914324006a396d183b778c
2012-10-15some namespacing improvementsLuboš Luňák
Change-Id: I95bd78340519bc1457385561b64c74e938b40bb2
2012-10-13remove debug outputLuboš Luňák
Change-Id: I719ce8870320f3bddd68fe26cf2c2b941e0a9403
2012-10-13compiler check to compare SAL_WARN/LOG areas against sal/inc/sal/log-areas.doxLuboš Luňák
Some of the areas are guesses I've added after seeing them, whoever feels reponsible for whichever part of the code feel free to adjust them. Change-Id: I2192de84d51cc2bc7c28fa84019d38b465985d15
generated by cgit (git 2.34.1) at 2024-12-29 14:13:56 +0000