summaryrefslogtreecommitdiff
path: root/beanshell
ModeNameSize
-rw-r--r--bsh-2.0b1-src.patch2917logplain
-rw-r--r--makefile.mk1747logplain
d---------prj70logplain
generated by cgit (git 2.34.1) at 2025-01-24 01:22:36 +0000
m-project/commit/1acffe81ee9117691812b9bf8747c03354177d15> "NFC: [clang] Template argument cleanups." Change-Id: I84bc276c21efcc11643ae7003e0fee6c7592130f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141860 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-05-02Just use Any ctor instead of makeAny in writerperfectStephan Bergmann (which needs one more false loplugin:redundantfcast suppression case) Change-Id: Ib8a72a510384f497bddaef5b812a46ea473481d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133703 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-04-25Introduce a better mechanism to suppress false loplugin warningsStephan Bergmann ...by annotating occurrences of false warnings with [-loplugin:<name>] comments in source files and letting individual plugins opt-in to watch out for such suppression annotations, rather than maintaining lists of excluded source files in the individual plugins. (See the new loplugin::Plugin::suppressWarningsAt.) Instead of making all calls to loplugin::Plugin::report check for suppression annotations, the intent is that this check will only be added opt-in to those places in the plugins that are prone to emitting false warnings. In general it is better to have plugins that don't produce false warnings in the first place, or at least let those warnings be addressed with trivial and harmless source code modifications, avoiding the need for any suppression mechanism. As a proof of concept, I have removed the exclude list from loplugin:redundantfcast and instead annotated the relevant source code. (And thereby found that three of the six originally excluded files didn't need to be excluded any more at all?) For now, this mechanism looks for comments (both //... and /*...*/, even documentation-style /**...*/) that overlap the current and/or the preceding line, because at least for code controlled by clang-format it is often easier to move comments to a line of their own, preceding the commented code. Looking also at the current line (and not only at the preceding one) opens the door for erroneous over-eager annotation, where an annotation that was meant to address a false warning on the current line would also silence a potentially true warning on the following line. This probably doesn't cause much trouble in practice, but is up for potential change. Change-Id: I91ce7a0e5248886a60b471b1a153867f16bb5cea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133365 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-04-21Fix typoAndrea Gelmini Change-Id: I0444ed426dddd36e464b59758545155e11e9c13a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133298 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2022-04-21tdf#55058 tdf#143875 EMF+ Fix display of dashed lines and line jointsBartosz Kosiorek With previous implementation, empty spaces between dashes were too long. Additionally line joints were not working correctly, after EMF+ reworking: tdf#111486 This commit fixes all these issues and additionally it is covering it with tests. Change-Id: I9404e566d2d7d3405ab817268ad9b1f538c200eb Change-Id: I523f92a928ab592ff175d0d01c1ad1a3bc22e324 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133207 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> 2022-03-11load ods/xlsx with full row attributes without allocating all columnsLuboš Luňák If there's e.g. an entire row bold, it's enough to set default attribute for unallocated columns. This also reverts the workaround from commit 297ab561c6754, as it's no longer necessary. Change-Id: I0b208709aeaff1c0d59da2410926876715cfe642 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131320 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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> 2021-10-19tdf#145203: FIREBIRD cannot create a tableJulien Nabet Regression from: https://cgit.freedesktop.org/libreoffice/core/commit/?id=1cf57765dd9a66982ecf9cd33687005a70c70c3f 2021-10-08 loplugin:moveparam in connectivity Change-Id: Iec0fa1597e63d42ee3a905bf55eff798b3f46177 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123787 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2021-09-09loplugin:redundantfcast ignore necessary temporariesNoel Grandin when passing data to a method that is of type Foo&& Change-Id: I0e6bcfb42d6ebcbc7cb19e510ab2010a2cc2bb7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121843 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-08-30Look through implicit MaterializeTemporaryExprStephan Bergmann ...which gets introduced when building with recent Clang 14 trunk against recent libstdc++ 12 trunk (though no idea what change exactly in either of those started to cause this) Change-Id: Icde11e16465c0deaefe76eb8d1065362d4551651 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121296 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2021-07-05store the SfxItemSet inside SfxSetItem by valueNoel Grandin rather than on the heap, avoiding an allocation Change-Id: I3f1504f9a2d4178a9ba59e98de182a0ab98cdce0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118356 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>