| Age | Commit message (Collapse) | Author |
|---|
|
<github.com/llvm/llvm-project/commit/cfe26358e3051755961fb1f3b46328dc2c326895>
"Reapply '[clang] Avoid re-evaluating field bitwidth'"
Change-Id: Ic31d5cd8251d0f83e7589e2f00e3c34789c75bad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180150
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...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>
|
|
Each plugin currently uses its own recursive AST run, which adds up.
This patch adds another shared plugin which internally contains all
(suitable) plugins and dispatches to them from the same one recursive
run. This patch converts ~25 plugins and for starmath's accessibility.cxx
reduces clang build time from 5.43s to 5.14s (and it's 4.39s without any
plugins). As there are almost 50 more plugins to go, this can theoretically
result in 4.56s final time, although probably not all plugins can be
that easily converted, if at all.
This mostly requires very little change in many plugins (see e.g.
BadStatics), some even work without any functionality change (e.g.
CharRightShift). Traverse* calls require some changes but are often
not that difficult. WalkUp* probably can't be supported, although some
plugins can(?) possibly be adjusted to not rely on them. And of course
some plugins can be left as they are, using their own recursive run.
See description at the top of generator.cxx for description of how to
convert a plugin.
The sharedvisitor.cxx source is generated based on scanning relevant
plugin sources using a clang-based scanner/generator. The generated
source is intentionally included instead of getting always generated,
as the generating currently takes some time, so it should get updated
in git whenever a change in a plugin triggers a source change in it.
Change-Id: Ia0d2e3a5a464659503dbb4ed6c20b6cc89b4de01
Reviewed-on: https://gerrit.libreoffice.org/68026
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
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>
|
|
Change-Id: I9e8cf6d7c2474f8c4c624dd9040890997c43f788
Reviewed-on: https://gerrit.libreoffice.org/61789
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
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>
|
|
Change-Id: I26734c13515394162d88351a1cbe2b20abdac865
|
|
(Where the change to basic/source/comp/codegen.cxx reveals that
loplugin:loopvartoosmall also needs the Clang < 3.9 workaround from
33ee8e61292af05627f5f72ea2f93ad80e715e46 "Work around bug in Clang 3.8".)
Change-Id: I9f23b9648bc11ca4136a0fbdd332570ba70ee77c
Reviewed-on: https://gerrit.libreoffice.org/39667
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Note the two "//TODO!" in the fix of the one newly found issue.
Change-Id: I181691da4b74cd55611452e002b37bd6798ff1e6
|
|
...where the "controlling expression" of any sort of loop contains a sub-
expression of the form
var < val
where the type of var is smaller than that of val. Theoretically, this could
turn up lots of false positives, but practically it didn't run into any. Most
findings have been cleaned up over the last weeks. There's just a handful
remaining places that are hard to clean up, so I flagged them here with
(deliberately awkward) sal::static_int_cast for later clean-up.
Change-Id: I0f735d46dda15b9b336150095df65cf247e9d6d3
Reviewed-on: https://gerrit.libreoffice.org/35682
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I81e97c5f720535b33dd3ce72d01151765e4e93a0
|
|
Change-Id: I114320ebaab9223b82b4fd9710c3cc221a836645
|
|
Change-Id: Ib4def3435eab4625645c5afe3b151f9f430564ac
|
|
Change-Id: I86ff38a90018a2ddfb2db3babf67168b0e6257a5
|
|
Change-Id: I5518e40a30bdad53470cc52b59eff04ab6d873d4
|
|
Change-Id: Icbe68b31d4ab04ca3cd9f572e3598413946a75c7
|
|
Change-Id: Icb31e51575f7fffd36be73bbd87a3c5e56c3aa26
|
|
Change-Id: I1e9768c08af0bc7caac6a39c13842ee9d8ad962c
|
|
Idea from bubli - look for loops where the index variable is of such
size that it cannot cover the range revealed by examining the length
part of the condition.
So far, I have only run the plugin up till the VCL module.
Also the plugin deliberately excludes anything more complicated than a
straightforward incrementing for loop.
Change-Id: Ifced18b01c03ea537c64168465ce0b8287a42015
|
