summaryrefslogtreecommitdiff
path: root/sal/qa/rtl
AgeCommit message (Collapse)Author
2017-11-21Fix typosAndrea Gelmini
Change-Id: I40b3a46d46f0586d086bdbe41876c088f8c1cb58 Reviewed-on: https://gerrit.libreoffice.org/45007 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jens Carl <j.carl43@gmx.de>
2017-11-11Avoid using O[U]StringConcat lvalues containing dangling refs to temporariesStephan Bergmann
...in code accidentally using auto like > auto const aURL = uri->getUriReference() + "/" > + INetURLObject::encode( > m_sEmbeddedName, INetURLObject::PART_FPATH, > INetURLObject::EncodeMechanism::All); > > uno::Reference<uno::XInterface> xDataSource(xDatabaseContext->getByName(aURL), uno::UNO_QUERY); in <https://gerrit.libreoffice.org/#/c/44569/1> "Properly construct vnd.sun.star.pkg URL" did (causing hard to debug test failures there). So make functions taking O[U]StringConcat take those by rvalue reference. Unfortunately, that also needed adaption of various functions that just forward their arguments. And some code in sc/qa/unit/ucalc_formula.cxx used CPPUNIT_ASSERT_EQUAL on OUStringConcat arguments in cases where that happened to actually compile (because the structure of the two OUStringConcats was identical), which needed adaption too (but which would arguably better use CPPUNIT_ASSERT_EQUAL_MESSAGE, anyway). Change-Id: I8994d932aaedb2a491c7c81c167e93379d4fb6e3 Reviewed-on: https://gerrit.libreoffice.org/44608 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-10-24Make testUtf8StringLiterals work when char is unsignedStephan Bergmann
...as is reportedly the case for Linux AArch64 Change-Id: I7e11c42f4437c8aad9dd734603fa7e0d458c9754
2017-10-23loplugin:includeform: salStephan Bergmann
Change-Id: I539ca8b9dee5edc5fc2282a2b9b0ffd78bad8b11
2017-09-24Map Windows code page 42 to RTL_TEXTENCODING_SYMBOLStephan Bergmann
<https://msdn.microsoft.com/en-us/library/windows/desktop/ dd374130(v=vs.85).aspx> "WideCharToMultiByte function" suggests that there now is CP_SYMBOL, "Windows 2000: Symbol code page (42)." And a little test program on Windows indicates that our RTL_TEXTENCODING_SYMBOL is working the same way as CP_SYMBOL, where MultiByteToWideChar maps 00..1F to U+0000..1F and 20..FF to U+F020..F0FF. At least CppunitTest_writerfilter_rtftok, when testing writerfilter/qa/cppunittests/rtftok/data/pass/EDB-18940-1.rtf, goes into case RTF_FCHARSET in RTFDocumentImpl::dispatchValue (writerfilter/source/rtftok/rtfdispatchvalue.cxx) with nParam matching aRTFEncodings[2] (i.e., a mapping from charset 2 to codepage 42, see writerfilter/source/rtftok/rtfcharsets.cxx), then passes 42 into rtl_getTextEncodingFromWindowsCodePage and obtains an unhelpful RTL_TEXTENCODING_DONTKNOW. testFdo72031 (sw/qa/extras/rtfexport/rtfexport2.cxx, CppunitTest_sw_rtfexport2) needed to be adapted, as the circled plus from the Symbol font is now internally represented as U+F0C5, not (somewhat bogusly) as U+00C5 (aka LATIN CAPTIAL LETTER A WITH RING ABOVE). But, when displayed with the Symobl font, the glyph that is actually shown remains the circled plus. Turns out changing rtl_getTextEncodingFromWindowsCodePage would start to make CppunitTest_sw_rtfimport fail: Sep 20 15:49:24 <sberg> vmiklos, with <https://gerrit.libreoffice.org/#/c/42477/>, testN823675 (sw/qa/extras/rtfimport/rtfimport.cxx) fails, the aFont.Name is not "Symbol"; sw/qa/extras/rtfimport/data/n823675.rtf contains a \fonttbl that specifies \f3 to have \fcharset2 (i.e., symbol font) and fontname "Symbol". However, RTFDocumentImpl::checkUnicode (writerfilter/source/rtftok/rtfdocumentimpl.cxx) converts m_aHexBuffer (containing "Symbol;") with nCurrentEncoding apparently being the encoding specified by \fcharset2 (i.e., now RTL_TEXTENCODING_SYMBOL instead of old RTL_TEXTENCODING_DONTKNOW), so the resulting OUString is garbage (instead of the byte-for-byte conversion to Unicode "Symbol;" that RTL_TEXTENCODING_DONTKNOW would do there); do you know whether such \fonttbl fontnames should actually be interpreted in the given \fcharset? Sep 20 15:49:24 <IZBot> gerrit: »Map Windows code page 42 to RTL_TEXTENCODING_SYMBOL« by Stephan Bergmann for master [NEW] Sep 20 15:51:15 <vmiklos> sberg: let me check if the spec covers that Sep 20 15:54:29 <mst_> sberg: i think the name is typically encoded in the font's encoding but probably they have to make a (likely undocumented) exception for symbol encoding Sep 20 15:57:46 <vmiklos> sberg: the spec only says that \fcharset is about the encoding of the content using that font, i don't see it described what would be the encoding of the font name itself Sep 20 15:58:51 <vmiklos> sberg: i'm not sure about if that encoding should or should not affect the encoding of the font name in general, but indeed at least for 2 (symbol encoding) you're right, Word doesn't encoding the font name with that encoding, either. Sep 20 15:59:30 <sberg> vmiklos, mst_, at the top of page 14 of Word2007RTFSpec9.docx I see "Note that runs of text marked with a particular font index (see \fN in the Font Table section) use the codepage for that font as given by \cpgN or implied by \fcharsetN, unless they use Unicode RTF described in the following section." Would that match what mst_ says? Sep 20 15:59:33 <vmiklos> so if it helps you case to handle at as e.g. ascii, just for that encoding, i think there would be no problem with that. Sep 20 16:00:07 <vmiklos> sberg: that still talks about the content using the font, not the strings (font names) in the font table itself, i think. Sep 20 16:01:17 <sberg> vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:02:16 <mikekaganski> loircbot: e.g. \af3 Sep 20 16:02:31 <mikekaganski> sberg: ^ Sep 20 16:02:47 <mst_> 04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:50 <IZBot> core - related: fdo#77979: writerfilter RTF import: read encoded font name - http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:52 <mst_> sberg: ^ Sep 20 16:04:05 <sberg> mst_, thanks; so there's likely an (implicit?) exception for \fcharset2, as you say Sep 20 16:04:33 <mst_> that's most plausible, our own font code is full of exceptions for "symbol fonts" too Sep 20 16:05:19 <sberg> mikekaganski, ENOCONTEXT Sep 20 16:05:36 <mikekaganski> sberg: [17:01:16] sberg: vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:06:32 <sberg> mikekaganski, so you say selection is done with \af3 instead of \f3? Sep 20 16:06:40 <mikekaganski> sberg: yes, in that case Sep 20 16:07:34 <mst_> i think there are several different keywords that apply fonts, but can't remember the whole list Sep 20 16:08:10 <mst_> \fN shoudl be one of them though Sep 20 16:22:18 <sberg> vmiklos, so who generated that sw/qa/extras/rtfimport/data/n823675.rtf, was it manually created and lacks a \cpgN before "Symbol"? Sep 20 16:29:17 <sberg> vmiklos, (after further reading of the RTF spec): disregard the "and lacks a \cpgN before 'Symbol'" part of my above question Sep 20 16:30:27 <mst_> sberg: i suggest not reading too much about encoding in RTF, it gets pretty lovecraftian pretty fast... Sep 20 16:32:58 <vmiklos> sberg: given how short that bugdoc is, i'm pretty sure i cut it down manually to something readable from a multi-MB real bugdoc Sep 20 16:33:07 <sberg> mst_, do you have a recommendation how I could get that "don't use symbol font encoding to read a symbol font's name" into writerfilter/source/rtftok/rtfdocumentimpl.cxx? RTFDocumentImpl::checkUnicode lacks the context to tell whether it is using m_aStates.top().nCurrentEncoding to convert a fontname, and the caller of checkUnicode (at the end of RTFDocumentImpl::resolveChars in this case) appears to lack the context, too Sep 20 16:33:12 <mst_> various Old Ones from The Time Before Unicode and their Backward Compatibility Tentacles etc. Sep 20 16:34:59 <sberg> vmiklos, anyway, that "so there's likely an (implicit?) exception for \fcharset2" hypothesis sounds sane, so we should probably implement it (if only you or mst_ can give me a good hint how...) Sep 20 16:35:13 <vmiklos> sberg: looking for a code pointer Sep 20 16:36:05 <mst_> sberg: m_aStates.top().eDestination == Destination::FONTENTRY should be the relevant check? Sep 20 16:36:17 <vmiklos> sberg: RTFDocumentImpl::text() is where the text is taken, Destination::FONTENTRY is the state on the parser stack which is a font entry in the font table. so to detect "your case" during decoding a byte array into a string, m_aStates.top().eDestination == Destination::FONTENTRY is what you want Sep 20 16:36:35 <vmiklos> ah good, two independent matching hints are promising ;) Sep 20 16:37:35 <sberg> mst_, vmiklos, ah; but what also looks dodgy is that checkUnicode operates there on "Symbol;" including the closing ";" of the full <fontinfo>, not just the <fontname> part of the <fontinfo> Sep 20 16:39:24 <vmiklos> sberg: i think we already assume that the only "token" in the font entry destination that is not bound to a control world (\foo) is the font name Sep 20 16:40:52 <vmiklos> sberg: writerfilter/source/rtftok/rtfdocumentimpl.cxx:1237 is where we simply strip away the trailing semicolon, there is no further separation between the font name and other character content inside the destination (apart from the control words and their arguments) Sep 20 16:42:18 <sberg> vmiklos, OK, thanks; I'll just pretend I haven't seen those dodgy details :) ...so I'm switching to (somewhat arbitrarily) RTL_TEXTENCODING_MS_1252 there now Change-Id: Iebd1bcecb7fa71c489798154d3356062b052775e Reviewed-on: https://gerrit.libreoffice.org/42477 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-18Some more WIN32_LEAN_AND_MEANMike Kaganski
Change-Id: Iadb0ebb66809c192fb817b8c7cf2f8cdb4d0b874 Reviewed-on: https://gerrit.libreoffice.org/42419 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-13Make reading UTF-8 strictStephan Bergmann
Consider non-shortest forms, surrogates, and representations of values larger than 0x10FFFF (which can even cover five or six bytes, for historical reasons) as "invalid" (they used to be considered as "undefined" instead). This is in response to fc670f637d4271246691904fd649358ce2e7be59 "svtools: HTML import: don't put lone surrogates in OUString" (which can now be reverted again in a follow-up commit). My fear would have been that some places in the code rely on the original, relaxed handling, but at least 'make check' still succeeded for me. Change-Id: I017e6c04ed3c577c3694b417167f853987a1d1ce
2017-07-25tell msvc our source code is written using utf-8Caolán McNamara
Change-Id: I4fb364ceb34e0851f2d04c403333bf428e8cfa98 Reviewed-on: https://gerrit.libreoffice.org/40305 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-07-17RTL_UNICODETOTEXT_INFO_{DEST|SCR}BUFFERTOSMALL should use TOO, not TOChris Sherlock
I have kept the old mispelled constant for backwards compatibility Change-Id: I128a2eec76d00cc5ef058cd6a0c35a7474d2411e Reviewed-on: https://gerrit.libreoffice.org/39995 Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-07-13use more OUString::operator== in forms..salNoel Grandin
Change-Id: I70d7e50f8c1e019524ccad915f0cca912c5035dc Reviewed-on: https://gerrit.libreoffice.org/39899 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-10simplify some OUString compareTo callsNoel Grandin
to either startsWith or == or != Change-Id: Ie4b4662f5b8e4532cbc1ab36910389e0b3d41ef0 Reviewed-on: https://gerrit.libreoffice.org/39750 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-06use OString::operator== in preference to ::equalsNoel Grandin
Change-Id: Ib291521963a791a9c6175964571e9d9895072acf Reviewed-on: https://gerrit.libreoffice.org/39646 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-14use more SAL_N_ELEMENTS part 2Noel Grandin
Change-Id: If00e371c3cd3ae616309a172c875faed016e391b Reviewed-on: https://gerrit.libreoffice.org/38773 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-09clang-tidy readability-non-const-parameterNoel Grandin
Change-Id: I7b2680898dbfc49185fb949349d81f4ac615a470 Reviewed-on: https://gerrit.libreoffice.org/38593 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-05-30teach redundantcast plugin about functional castsNoel Grandin
Change-Id: Iac8ccd17d9e46ebb2cb55db7adb06c469bbd4ea0 Reviewed-on: https://gerrit.libreoffice.org/37910 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-05-17Add some unit tests for rtl_math_StringFormat_GEike Rathke
Change-Id: I010c35905789d2c5f60f7f1c4d9ad4caf60146ee
2017-05-09cleanup osl/diagnose.h includesJochen Nitschke
with command > git grep -l osl/diagnose.h *.cxx | xargs grep -L -w 'OSL_\w*' | xargs sed -i '/#include *\(<\|\"\)osl\/diagnose.h\(>\|\"\).*/d' headers need more work Change-Id: I906519ebbd47a04703b4fa5943b2f7abea7a97ab Reviewed-on: https://gerrit.libreoffice.org/37350 Tested-by: Jochen Nitschke <j.nitschke+logerrit@ok.de> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-05-04Replace all OUString("") with OUString()Arnaud Versini
Change-Id: Ie14c4d76cb61cfbe0410103adfc1afc8ade0f3e0 Reviewed-on: https://gerrit.libreoffice.org/37146 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-04-28loplugin:salunicodeliteral: salStephan Bergmann
Change-Id: I1b7c3f8de5b09c96e27aa9124096b00638afb3f3
2017-04-28loplugin:cppunitassertequals: salStephan Bergmann
Change-Id: I6ba9a18a1d227461e023259662635e3008ad7c9b
2017-04-25tools: svstream.hxx needs only errcode.hxx & not errinf.hxxChris Sherlock
Change-Id: Ia28e35ae5af4f601e9a586a3deffbcd61702b0ca Reviewed-on: https://gerrit.libreoffice.org/36896 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-04-06Improved loplugin:redundantcast, static_cast on arithmetic types: salStephan Bergmann
Change-Id: I7caadbc06b2266800666151de75d799c42148aca
2017-04-04Finally switch MSVC to sal_Unicode = char16_t, tooStephan Bergmann
There is lots of (Windows-only) code that relied on sal_Unicode being the same as wchar_t, and the best change may be different in each case (and doing the changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding functions to sal/types.h, remove their uses one by one again, and finally drop those functions again. Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea Reviewed-on: https://gerrit.libreoffice.org/36077 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-30remove type decorations on char literalsJochen Nitschke
they are only needed where type deduction fails. left them in defines for now. Change-Id: I7f002dd6bc7acc083c73b6c64076de6dd28d0b09 Reviewed-on: https://gerrit.libreoffice.org/35893 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-25Fix typosAndrea Gelmini
Change-Id: I5fc62060e7d01c6b492a0e91323f753cc676bf71 Reviewed-on: https://gerrit.libreoffice.org/35639 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-03-02Remove HAVE_CXX11_UTF16_STRING_LITERAL, always true nowStephan Bergmann
...after 84b36c704d73362d4d86dc9e9c0efa0625958347 "Drop support for MSVC 2013". Make this a fatal configuration error for now. The check should be removed completely after LO 5.4 branch-off. Change-Id: If2f196abb93607dde9ba5c4f04d219679585e633 Reviewed-on: https://gerrit.libreoffice.org/34822 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-10Remove MinGW supportStephan Bergmann
In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-02-01loplugin:useuniqueptr extend to check local varsNoel Grandin
just the simple and obvious case for now, of a local var being allocated and deleted inside a single local block, and the delete happening at the end of the block Change-Id: I3a7a094da543debdcd2374737c2ecff91d644625 Reviewed-on: https://gerrit.libreoffice.org/33749 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-01-25loplugin: unnecessary destructor oox..saxNoel Grandin
Change-Id: Ie12bfabc92bce04d702f3e77aa5896366e49245e Reviewed-on: https://gerrit.libreoffice.org/33509 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-01-11loplugin:stringconstant: handle OStringBuffer::appendStephan Bergmann
Change-Id: I283da52c0ee2b63c19e31e9a61ab24997c037a6a
2017-01-11Some loplugin:conststringvar/stringconstant improvements: salStephan Bergmann
Change-Id: I8b5d81c2b51f846a24fd1f7f9cdd831f1ea54ea5
2017-01-10New loplugin:conststringvar: salStephan Bergmann
Change-Id: Ia66415ff9ee67958e84cfff7eda082cdbfc9b9b9
2017-01-09New loplugin:externvar: salStephan Bergmann
Change-Id: Iefc33784f21e7a0b88c8d6308618926e38ab8554
2016-12-23tdf#97283: Merge sal rtl tests to one makefileMatúš Kukan
Change-Id: I1b78276e08feef9b6f49e5abe002391c50a8d2cc Reviewed-on: https://gerrit.libreoffice.org/32143 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Matúš Kukan <matus@libreoffice.org>
2016-12-17Make OUStringLiteral more usefulStephan Bergmann
...by: * making the OUStringLiteral ctor non-explicit (to be exploited in a follow-up commit) * adding (LIBO_INTERNAL_ONLY) overloads to OUString/OUStringBuffer functions that can now take OUStringLiteral in addition to taking "real" string literals (Keeping the number of overloads smaller by replacing the ConstCharArrayDetector overloads with ones taking OUStringLiteral (for LIBO_INTERNAL_ONLY, at least) and relying on the now-implicit conversion from "real" string literals to OUStringLiteral unfortunately would not work: Both OUString and OUStringLiteral argubably need implicit conversions from "real" string literals, so any function overloaded for OUString and OUStringLiteral would be ambinguous when called with a "real" string literal. And removing the OUString ctor taking a "real" string literal and relying on an implicit conversion chain from "real" string literal to OUStringLiteral to OUString doesn't work because it would involve two user- provided conversions.) Change-Id: I14433fc1605b048807f60b3a3e14f92221d3a226 Reviewed-on: https://gerrit.libreoffice.org/32097 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-16Typo in meant-to-be-overloading function nameStephan Bergmann
Change-Id: I65ab9176b39a436afce23e6bd4423ebf76219166
2016-12-06Comment cppcheck accessForwarded as harmlessStephan Bergmann
Change-Id: I2692ba63f010b61e7b4c1fe54368f4dac9c42d60
2016-11-25loplugin:stringconstant: look into 'char const * const var = "..."'Stephan Bergmann
Change-Id: I52a97b8ec273509131c2200e47527221cb62d7ee
2016-10-14CppunitTest_desktop_lib: fix loplugin:cppunitassertequals warningsMiklos Vajna
And also address a few new warnings in sal, plus silence such warnings in salhelper till we can't print typeids out of the box. Change-Id: I38049146710b6885f6a874bf74eedbc38b4d4651 Reviewed-on: https://gerrit.libreoffice.org/29809 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-12Don't allow O[U]StringBuffer in string concatenationStephan Bergmann
...as OStringBuffer b("foo"); b = "bar" + b; doesn't work as one might expect (see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2016-October/075464.html> "concat of OUStringBuffer". That feature was LIBO_INTERNAL_ONLY, anyway. And of the affected places, MethodDescriptor::getSignature (codemaker/source/javamaker/javatype.cxx) was the only one that would actually have benefitted. Change-Id: Ib84266f43e40c42c2e428f0c0616db8cfa90adff
2016-10-02unit test cases for approxEqual() and approxSub()Eike Rathke
Change-Id: I4aa53d83feaccd3d08c69a35cee2fa84f1ec0964 Reviewed-on: https://gerrit.libreoffice.org/29429 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-01Fix typosAndrea Gelmini
Change-Id: I6aeda978911b25caa45d4e459e581fc743e93d2c Reviewed-on: https://gerrit.libreoffice.org/29442 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-09-29tdf#83306 add unit test for compareWithLength and '\0'Michael Stahl
Change-Id: Iba48390035c560ea499c7fd793d5dd84d1f63cf0
2016-09-20CPPUNIT_ASSERT_EQUAL disambiguationStephan Bergmann
Change-Id: I31d30627badb08469f7e0fd3ded957df78b58275
2016-09-20Related cid#1371289: Work around missing OUStringBuffer move semanticsStephan Bergmann
...by adding more assign op overloads instead Change-Id: I2d2e1b7f19d1b57528707ed5a5cce94b5fa5c2d0
2016-09-15loplugin:singlevalfields in l10ntools..saxNoel Grandin
and ignore URE headers in the plugin Change-Id: I939df744c1173cf0f67d515f6c3fb4ac4cb25588
2016-09-13loplugin:override: No more need for the "MSVC dtor override" workaroundStephan Bergmann
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-09-02Fix MSVC 2015 buildStephan Bergmann
...which has HAVE_CXX11_UTF16_STRING_LITERAL but cannot use chart16_t string literals with ConstCharArrayDetector (which uses sal_Unicode) as long as sal_Unicode is still wchar_t instead of char16_t for MSVC. Change-Id: I7c55e0361d1c8c717467d5ab6c942bce3569f3a7
2016-08-30Let OUStringLiteral1 take its arg as ctor arg, not template argStephan Bergmann
...which makes it more flexible, can now also be used on non-const arguments. The drawback of the argument no longer being a compile-time constant is remedied by making the ctor constexpr. Change-Id: Ia4903a2cc86791fece92eac0cb8406b6659dd19d
2016-08-29Make OUStringLiteral1 a wrapper around UTF-16 instead of just ASCIIStephan Bergmann
...not merely an ASCII character Change-Id: Id2b381b35fe3a15574728ed973d60263dfef7249 Reviewed-on: https://gerrit.libreoffice.org/28446 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-08-09 18:28:36 +0000