aboutsummaryrefslogtreecommitdiff
path: root/source/it/svx
AgeCommit message (Expand)Author
2024-01-25update translations for 24.2.0 rc3Christian Lohmaier
2024-01-08update translations for master/24-2Christian Lohmaier
2023-12-15update translations for master/24-2Christian Lohmaier
2023-12-04update translations for masterChristian Lohmaier
2023-11-02update translations for masterChristian Lohmaier
2023-10-11update translations for masterChristian Lohmaier
2023-09-28update translations for masterChristian Lohmaier
2023-09-12update translations for masterChristian Lohmaier
2023-08-07update translations for 7.6.0 rc3Christian Lohmaier
2023-07-26update translations for 7.6.0 rc2Christian Lohmaier
2023-07-07update translations for master/7.6.0 rc1Christian Lohmaier
2023-06-12update translations for 7.6/masterChristian Lohmaier
2023-06-07update translations for master/7.6.0 beta1libreoffice-7-6-branch-pointChristian Lohmaier
2023-05-03update translations for masterChristian Lohmaier
2023-04-27update translations for masterChristian Lohmaier
2023-04-19update translations for masterChristian Lohmaier
2023-03-20update translations for masterChristian Lohmaier
2023-03-13update translations for masterChristian Lohmaier
2023-03-03update translations for masterChristian Lohmaier
2023-02-09update translations for 7.5.1 rc1/masterChristian Lohmaier
2023-01-23update translations for 7.5.0 rc3/masterXisco Fauli
2023-01-09update translations for 7.5.0 rc2 / masterChristian Lohmaier
2022-12-19update translations for 7.5.0 rc1/masterChristian Lohmaier
2022-12-12update translations for master/7.5Christian Lohmaier
2022-11-23update translations for masterChristian Lohmaier
2022-11-14update translations for masterChristian Lohmaier
2022-10-22update translations for masterChristian Lohmaier
2022-10-10update translations for masterChristian Lohmaier
2022-07-15update translations for 7-4/masterChristian Lohmaier
2022-07-06update translations for 7.4.0 rc1/masterChristian Lohmaier
2022-07-04update translations for 7.4/masterChristian Lohmaier
2022-06-15update translations for master/7.4Christian Lohmaier
2022-06-10update translations for master/7.4.0 beta1libreoffice-7-4-branch-pointChristian Lohmaier
2022-06-09update translations for master/7.4.0 beta1Christian Lohmaier
2022-05-25update translations for master/7.4Christian Lohmaier
2022-05-12update translations for 7.4.0 alpha1Christian Lohmaier
2022-05-04update translations for masterChristian Lohmaier
2022-04-26update translations for masterChristian Lohmaier
2022-04-04update translations for masterChristian Lohmaier
2022-02-18update translations for masterChristian Lohmaier
2022-01-31update translations for masterChristian Lohmaier
2022-01-10update translations for 7.3.0 rc2/masterChristian Lohmaier
2021-12-21update translations for 7.3.0 rc1Christian Lohmaier
2021-11-25update translations for 7.3.0 beta1libreoffice-7-3-branch-pointChristian Lohmaier
2021-11-24update translations for master/7.3.0 beta1Christian Lohmaier
2021-11-16update translations for masterChristian Lohmaier
2021-10-29update translations for 7.3.0 alpha1Christian Lohmaier
2021-10-25update translations for masterChristian Lohmaier
2021-09-27update translations for masterChristian Lohmaier
2021-09-14update translations for masterChristian Lohmaier
generated by cgit (git 2.34.1) at 2024-12-24 16:03:15 +0000
-0-0'>libreoffice-7-0-0 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/include/cppu
AgeCommit message (Collapse)Author
2022-01-15Let loplugin:nullptr look into template instantiationsStephan Bergmann
It missed some occurrences of 0 when only looking into uninstantiated template code, as Clang doesn't model them with an ImplicitCastExpr, even if the target is known to be a (dependent) pointer type. Looking into all template instantiations of course carries the risk that a given use of 0 is meant to be interpreted as a pointer in some and as an integer in other instantiations. But the only case where that happened in the current code base is RegistryValueList::getElement (include/registry/registry.hxx), where {} is arguably a better choice anyway. (And which would presumably also hold for any future such cases.) Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-02tdf#130978 Added comment to all published APImsrijita18
Change-Id: I744788bde9778f85ccd9d7667e19d16842900a29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110248 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-21tdf#123936 Formatting files in module include with clang-formatPhilipp Hofer
Change-Id: I0507dd797cd5a35e0ae14f4b69ee4e172d08a71a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105681 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2017-10-23loplugin:includeform: UNO API include filesStephan Bergmann
Change these back to consistently use the "..." form to include other UNO API include files, for the benefit of external users of this API. Change-Id: I9c9188e895eb3495e20a71ad44abfa2f6061fa94
2017-03-25Fix typosAndrea Gelmini
Change-Id: I389542e18fcf71011f22919743b5280779f449fd Reviewed-on: https://gerrit.libreoffice.org/35632 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-03-24Better check for 'defined LIBO_INTERNAL_ONLY'Stephan Bergmann
(to avoid warnings about undefined macros in external code) Change-Id: Ie1007207b22c19a3d9d96f0f94070c32d417595a
2017-03-03Remove redundant 'inline' keywordStephan Bergmann
...from function definitions occurring within class definitions. Done with a rewriting Clang plugin (to be pushed later). Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8 Reviewed-on: https://gerrit.libreoffice.org/34874 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-05-03Handle wchar_t as native C++11 type on windowsDavid Ostrovsky
The option /Zc:wchar_t- prevented to use wchar_t as a built-in type according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t was not implemented as a built-in type, but was declared in wchar.h as a typedef for unsigned short. Now, years later after the end of life this outdated toolchain, there is no reason not to use native type. The only issue could be the ABI compatibility. But on a quick look at least, it looks like none of the mangled C++ symbols in the stable URE interface actually depend on wchar_t. We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice 5.2, though. Change-Id: I8d6b380660859efa44c83c830734978d31d756a0 Reviewed-on: https://gerrit.libreoffice.org/22589 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-02-09Remove excess newlinesChris Sherlock
A ridiculously fast way of doing this is: for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \ --exclude-dir=workdir --exclude-dir=instdir '^ {3,}' .) do perl -0777 -i -pe 's/^ {3,}/ /gm' $i done Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c Reviewed-on: https://gerrit.libreoffice.org/22224 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
2015-11-28Adapt to true wchar_t in clang-clStephan Bergmann
Change-Id: I14c2dc0be12151b5d4ea2ba3b65030f6f4494905
2015-11-18Use C++11 char16_t for sal_UnicodeStephan Bergmann
...in LIBO_INTERNAL_ONLY, __cplusplus, non-MSVC case. It turns out that sal_Unicode happens to not be mangled into any symbols that make up the stable URE interface, so (for LIBO_INTERNAL_ONLY, at least) we are free to replace the typedef to sal_uInt16 with a typedef to any integral type layout-compatible with that. (sal_Unicode does appear in some symbols in sal's PRIVATE_textenc.1 section, but that is private between the sal and sal_textenc libraries, so changing those symbols does not require a change of SONAME.) C++11 chart16_t is the obvious choice (and will ultimately allow using u"..." to write literals of type array-of-sal_Unicode). Reportedly, char16_t is supported since GCC 4.4 and Clang 2.9 but will only be available in MSVC 2015. For plain C, we continue to use sal_uInt16. We could theoretically use C11 char16_t from <uchar.h>, but at least the Mac OS X 10.11 SDK still does not offer that C11 header. For MSVC, we continue to use wchar_t (which is actually unsigned short, due to /Zc:wchar_t-) for now. Potential options there include dropping /Zc:wchar_t- and using true wchar_t, or using C++11 char16_t once support for MSVC 2013 is dropped. Some code needed to be adapted that was written in a way assuming that sal_Unicode is unsigned short (which indicates that changing sal_Unicode for non-LIBO_INTERNAL_ONLY would be an ABI change). OUStringBuffer::append can now differentiate between being called with sal_Unicode (to append a single character) and erroneously being called with sal_uInt16 (intending to append a number's textual representation, for which the sal_Int32 overload must be used instead). Bugs found are 379fe0409e7973b36210cffa3dd1dfd4032f0ecc "Assume that this code wants to append a number, not a character" and dc148335a6a438848325f24c49198fba81043279 "Assume this wants to append the numerical representation." The GDB support for pretty-printing of sal_Unicode-related data in solenv/gdb/libreoffice/sal.py can presumably be simplified now. Change-Id: I445b3a80e65b7cb004d9e08b38bdc9ee93bc9401 Reviewed-on: https://gerrit.libreoffice.org/20036 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2015-11-10Missing includes (for NULL)Stephan Bergmann
Change-Id: Id2359f6ff4bddb2afbc0b346e17cd858f00179e3
2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann
Change-Id: I17eb40b2923793280ea220e519f97563c8490a19
2015-10-21com::sun::star->css in include/cppuNoel Grandin
Change-Id: I85e866fc5b52c3bbedd5b54549dba018b70be2f7 Reviewed-on: https://gerrit.libreoffice.org/19485 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>