summaryrefslogtreecommitdiff
path: root/sw/source/filter/ascii/parasc.cxx
AgeCommit message (Collapse)Author
2023-10-03replace ErrorInfo with simpler mechanismNoel Grandin
Instead of returning ErrCode class everywhere, return a new class ErrrCodeMsg, which combines an ErrCode with the other parameters that are used to control the error reporting. I do not change everything that uses ErrCode here, I started from SfxBaseController/SfxMedium and worked outwards. This change serves two purposes (1) Replace the extremely whacky ErrorInfo mechanism we were using to smuggle information into the error handler reporting mechanism with a very straightforward approach of just combining it into the error class. (2) Allow us to capture the source location that produced the error, which makes debugging the source of a problem soooo much easier. Change-Id: I978b8f00c9851b41a216c7ebdef2ef94251d5519 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157440 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-28SfxMedium::GetItemSet never returns nullptrMike Kaganski
Change-Id: Ibfc98a49022aa09ebf5315e5d3328308c1e51d66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154997 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-06tdf#154000 tdf#70423 sw: fix crash/freezing with huge text filesLászló Németh
It was not possible to load or edit text files with very long lines any more, because removed wrapping of the lines resulted freezing and crash. This reverts commit 745898eb2af2686ffbdfdc0e44984db67b172a59 "tdf#70423 Remove txtimport break in 10k chars line", keeping only its unit test. Fix also tdf#70423 by increasing the wrap limit from 10000 to 250000 characters, which still permit to load e.g. 50 MB character or longer text lines, and to edit 5 MB or longer text lines without crash or freezing. Details: trying to load a relatively short 76 MB character length text line shows a non-linear slowing down during the load, resulting program crash after freezing 10 minutes. Now this file is opened within seconds again, allowing to modify, select and copy of the text before the full load of the document (with linear speed). Loading a much shorter 5 MB character length text line resulted an unusably slow editing previously: waiting half minutes for changing, selecting or copying text parts. Manual test Create a text file with a 76 MB character long line, and open it: $ seq 10000000 | tr '\n' ' ' >numbers.txt $ soffice numbers.txt Note: the reverted commit had also a paragraph limit exceeded error using unlimited paragraph length, because that is limited in 4 GiB characters since version 4.3, see tdf#30668 and commit ba27366f3d6bc6b209ecd5c5cb79a9ee5315316a "Resolves: #i17171# Writer paragraph cannot be longer than 65534 characters". Change-Id: If91e340a8aac4d4ebc4097b19cfa854b5659da3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148169 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-01-02tdf#70423 Remove txtimport break in 10k chars lineRadhey Parekh
This patch fixes the tdf#70423 which is an unexpected line break for ~10k characters. The fix consists of removing part of the code that creates a new paragraph when reaching ~10k characters. The limit was not exactly 10k characters, because the code tried to break at space character when reaching around 10k-100 characters. A test is also created, which can be checked by invoking: make CPPUNIT_TEST_NAME="testTdf70423" -sr CppunitTest_sw_txtimport The test checks that there should be exactly 1 paragraph with 30k characters inside it. Change-Id: Ic37c2b6eb89b52b533e34dd117b9635b9608bab2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121548 Tested-by: Hossein <hossein@libreoffice.org> Reviewed-by: Hossein <hossein@libreoffice.org>
2022-08-20use more SwPosition::GetNodeNoel Grandin
Change-Id: Ib09191384e0ae3175a564edf9387e4de00ce851d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138583 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-12no need to allocate this on heapNoel Grandin
Change-Id: I0a95d901d8f0b8660ad2dddf38a47b57dedc432e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138150 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-11unique_ptr->optional in SwASCIIParserNoel Grandin
Change-Id: I46cb62609c738a12cb988aa9c09171403e33c619 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138105 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-05use more SwPosition::AssignNoel Grandin
as part of the process of hiding the internals of SwPosition these are still the easy ones, i.e. no functional change intended Change-Id: Ibb2adf17de47bab5374730b508d9c020991a945e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137802 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-02introduce SwPosition::GetContentIndexNoel Grandin
as part of the process of hiding the internals of SwPosition largely done by doing: git grep -lF 'nContent.GetIndex' | xargs perl -pi -e 's/\bnContent\.GetIndex/GetContentIndex/g' Change-Id: I12684071a6666c365dbadbab2a4b37cf51b274d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137695 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-21introduce SwNodeOffset strong typedefNoel Grandin
for indexing into node children. Replaces various usage of sal_uLong, tools::Long, sal_uInt32 with an underlying type of sal_Int32. Also add a NODE_OFFSET_MAX constant to replace usage of ULONG_MAX Change-Id: I2f466922e1ebc19029bb2883d2b29aa4c0614170 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123892 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-24no need to allocate these SwPaM on the heapNoel Grandin
Change-Id: Ief142e6410599ea50aee4065d843d7eaea55e21c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122578 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-22no need to allocate these SfxItemSet on the heapNoel Grandin
Change-Id: I21b34386d3f2f408da329b0e5888566cbb126d0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122402 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-19loplugin:constmethodsNoel Grandin
Change-Id: I786096b989daa6004a6527aafbe825b6f0a22d90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120710 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-18loplugin:passstuffbyrefNoel Grandin
Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-19Move svl::Items to include/svl/whichranges.hxx, and unify its usageMike Kaganski
... in WhichRangesContainer and SfxItemSet ctors. Now it's not needed to explicitly use 'value' in WhichRangesContainer's ctor, or create an instance for use in SfxItemSet ctor (svl::Items is already defined as a template value of corresponding type). Instead of WhichRangesContainer Foo(svl::Items<1, 2>::value); SfxItemSet Bar(rItemPool, svl::Items<1, 2>{}); now use: WhichRangesContainer Foo(svl::Items<1, 2>); SfxItemSet Bar(rItemPool, svl::Items<1, 2>); Change-Id: I4681d952b6442732025e5a26768098878907a238 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119157 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-06tdf#142669 Consider BOM on text encoding detectiontobias
Return a flag if the auto detected text has a BOM. Save the flag in SwAsciiOptions so that BOM gets set correctly when file is written. Change-Id: I358c3ba243bc326a552c2dc24773c94f8319c700 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116759 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-04tdf#120574 Store Ascii Options for Later Savingtobias
store auto detected/configured ascii options in medium. use stored ascii settings for saving and text encoding settings dialog. Change-Id: I88e2d54923bfcf5d7c460ef3b89c36fc002c5097 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116678 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-17sw: prefix members of SwASCIIParser, SwASC_AttrIter, ...Miklos Vajna
... SwTableProperties_Impl and SwViewShell See tdf#94879 for motivation. Change-Id: I7c8fe1f95d9ff1dbd7b9980845ff7fdfb36d1e26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115691 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-20use tools::Long in swNoel
Change-Id: I44be72b3a9b14823ec37a3c799cffb4fb4d6e1de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104527 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-04DocxTableStyleExport never passed a null SwDoc*Caolán McNamara
ditto: SwASCIIParser ctor SwNumRule::CopyNumRule SwDataChanged ctor Change-Id: I0f731ef2856eb70bd5fff5372ee7bc769e1f8bd3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103922 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-04change these sal_uLong to sal_SizeCaolán McNamara
Change-Id: I5823283702b38d4b928cf0bee8645eafd10fe58f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103873 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-02crashtesting: an odd number of bytes for RTL_TEXTENCODING_UCS2 encodingCaolán McNamara
seen with id:000316,src:000190+000204,op:splice,rep:32.doc Change-Id: Ia4eb13ed617828f0d35bed26651a7b9e9a4b6056 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103860 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-31loplugin:flatten in sw/core/view..sw/core/htmlNoel Grandin
Change-Id: I793811af353fe61b12e5e89da2056fb58108e9dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99852 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-10loplugin:buriedassign in swNoel Grandin
limited this only fixing assignments inside "if" statements, since other things are harder to change Change-Id: If3188a3e3d5fcd94123211c97fee097ece5e2797 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95990 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-16tdf#133077: fix lone CR handling in plain text clipboard on WindowsMike Kaganski
Failing to treat CRs without corresponding LFs resulted in 0 inserted in the place of the CR, but the text up to this position not inserted, and pLastStt not updated. Thus all following text was dropped when the insertion was finally performed (when CRLF or EOF was reached), because of the 0 marking end of inserted text. But that was inconsistent with how other Windows applications treated stand-alone CRs, and also with our own handling of them when they happened in the end of the internal read buffer. Change-Id: Idf4876b0cccd4aa3f14f6efede54d27670f55c35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94277 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-13Revert "loplugin:constfields in sw"Noel Grandin
This reverts commit 4969f4c0d3e2581aaa8a5b5a5769840fa6b6f8ea. Change-Id: I527e9366b05e8a20633720e334395b285991c524 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90473 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-23sal_Char->char in swNoel Grandin
Change-Id: I63fb87a8e8eaf9c9da7bf7b8b6f5706222ffcc07 Reviewed-on: https://gerrit.libreoffice.org/85730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-20tdf#42949 Fix IWYU warnings in sw/source/filter/*/*cxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I87263017cb0802c9f5ca21d630bf3701b9c5e73a Reviewed-on: https://gerrit.libreoffice.org/85167 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-16sw: fail loading when the fallback text detection failsAshod Nakashian
When we document in question fails to match any known type, we try to open as plain text (and convert to a Writer doc). However we should not display non-text when we have failed to detect ascii or unicode contents in the file. This happens with corrupted documents, for example, where we end up displaying non-printable binary data. Change-Id: Iccc158a4cb6051a8b17ba01987a30a9882a27fa9 Reviewed-on: https://gerrit.libreoffice.org/75512 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit d1f6f27e2a014aa55e2762f1209dc520fb183404) Reviewed-on: https://gerrit.libreoffice.org/78452 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/82099 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-07o3tl::make_unique -> std::make_unique in swGabor Kelemen
Since it is now possible to use C++14, it's time to replace the temporary solution with the standard one Change-Id: I871312c1077439377c67b76112f38b7019fa6fb1 Reviewed-on: https://gerrit.libreoffice.org/67376 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-11-19tdf#42949 Fix IWYU warnings in include/vcl/[ab]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: If18c80fc64e55d797953e24e40e5d5e62bd9c625 Reviewed-on: https://gerrit.libreoffice.org/63453 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-10-15add SvStream::TellEndNoel Grandin
and simplify callsites to use it instead of the current "seek to end, find pos, seek back to original pos" pattern Change-Id: Ib5828868f73c341891efc759af8bd4695ae2f33c Reviewed-on: https://gerrit.libreoffice.org/61738 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-03loplugin:constfields in swNoel Grandin
Change-Id: I1eb6583bb9ec815bc0564b0d7c676f5b1fb9045f Reviewed-on: https://gerrit.libreoffice.org/61177 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-18loplugin:useuniqueptr in AsciiReader::ReadNoel Grandin
Change-Id: Id8701c91d272850368db80b1ebabf11ea2a028f5 Reviewed-on: https://gerrit.libreoffice.org/60604 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-04-23sw: prefix members of ReaderMiklos Vajna
Change-Id: Ia4210410047ce3b37113cfe0d4dff5bb7122baf2 Reviewed-on: https://gerrit.libreoffice.org/53307 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-03-09sw: fix some IWYU warningsMiklos Vajna
Change-Id: Idb8ad6cda75b7112280ae71b4340d0187a602794 Reviewed-on: https://gerrit.libreoffice.org/50974 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-01-19tdf#115088: Pasting multi-line text from external source behaves strangelyTamás Zolnai
Regression from: e68b6e349c31ac1376e90218013e1e7612f2b522 AppendTextNode might be sufficient for import (when there is no content in the document), but for clipboard operations better to use the original SplitNode method. Change-Id: I7de3e9bc9c5356acb0b4cc43927a0d39079522b2 Reviewed-on: https://gerrit.libreoffice.org/48124 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-11-22drop duplicate methodCaolán McNamara
Change-Id: Idadd0a64e41cd02f5167b275081c3576a6224b12 Reviewed-on: https://gerrit.libreoffice.org/45075 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-08-27convert code-class in ErrCode to scoped enumNoel Grandin
Change-Id: I9aa8703921308d6fee8bae9ee2d7b29e19181cc7 Reviewed-on: https://gerrit.libreoffice.org/41601 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-22Convert ErrCode area to scoped enumNoel Grandin
Change-Id: Ifa365bbac3c7eb21da9381ec8bb3be6b6785016b Reviewed-on: https://gerrit.libreoffice.org/41402 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-21remove dead sw error codesNoel Grandin
and inline some macros Change-Id: Ida8db46bec4fcec46a779da0180fe3bf1a1af59d Reviewed-on: https://gerrit.libreoffice.org/41375 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-21migrate to boost::gettextCaolán McNamara
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
2017-07-17Remove duplicated includesAndrea Gelmini
Change-Id: Iba098ff1c96fb6f830e136102f687b345fb958ef Reviewed-on: https://gerrit.libreoffice.org/39981 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-07-11loplugin:useuniqueptr in swNoel Grandin
Change-Id: I50c8697d51c480c668c66a1cdc2c670575a1ec37 Reviewed-on: https://gerrit.libreoffice.org/39804 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-21convert ErrCode to strong typedefNoel Grandin
would have preferred to re-use o3tl::strong_int, of which this is a modified copy, but there are lots of convenience accessors which are nice to define on the class. Change-Id: I301b807aaf02fbced3bf75de1e1692cde6c0340a Reviewed-on: https://gerrit.libreoffice.org/38497 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-16Make SfxItemSet ranges correct by constructionStephan Bergmann
This is a follow-up to 45a7f5b62d0b1b21763c1c94255ef2309ea4280b "Keep WID ranges sorted, and join adjacent ones". While SfxItemSet::MergeRange relies on the m_pWhichRanges being sorted (and, under DBG_UTIL, asserts if they are not), the various SfxItemSet constructors curiously only check (via assert or DBG_ASSERT) that each individual range has an upper bound not smaller than its lower bound. Arguably, all SfxItemSet instances should fulfill the stronger guarantees required and checked by MergeRange. And in many cases the ranges are statically known, so that the checking can happen at compile time. Therefore, replace the two SfxItemSet ctors taking explicit ranges with two other ctors that actually do proper checking. The (templated) overload taking an svl::Items struct should be used in all cases where the range values are statically known at compile time, while the overload taking a std::initializer_list<Pair> is for the remaining cases (that can only do runtime checking via assert). Most of those latter cases are simple cases with a single range covering a single item, but a few are more complex. (At least some of the uses of the existing SfxItemSet overload taking a const sal_uInt16* pWhichPairTable can probably also be strengthened, but that is left for another day.) This commit is the first in a series of two. Apart from the manual changes to compilerplugins/clang/store/sfxitemsetrewrite.cxx, include/svl/itemset.hxx, and svl/source/items/itemset.cxx, it only consists of automatic rewriting of the relevant SfxItemSet ctor calls (plus a few required manual fixes, see next). But it does not yet check that the individual ranges are properly sorted (see the TODO in svl::detail::validGap). That check will be enabled, and the ensuing manual fixes will be made in a follow-up commit, to reduce the likelyhood of accidents. There were three cases of necessary manual intervention: * sw/source/core/unocore/unostyle.cxx uses eAtr of enum type RES_FRMATR in braced-init-list syntax now, so needs explicit narrowing conversion to sal_uInt16. * In sw/source/uibase/uiview/formatclipboard.cxx, the trailiing comma in the definition of macro FORMAT_PAINTBRUSH_FRAME_IDS needed to be removed manually. * In svx/source/svdraw/svdoashp.cxx, svx/source/svdraw/svdotext.cxx, sw/source/uibase/app/docstyle.cxx, sw/source/uibase/shells/frmsh.cxx, sw/source/uibase/shells/grfsh.cxx, and sw/source/uibase/shells/textsh1.cxx, some comments had to be put back (see "TODO: the replaced range can contain relevant comments" in compilerplugins/clang/store/sfxitemsetrewrite.cxx). A few uses of the variadic form erroneously used nullptr instead of 0 for termination. But this should have been harmless even if promoted std::nullptr_t is larger than promoted sal_uInt16, assuming that the part of the nullptr value that was interpreted as sal_uInt16/promoted int was all-zero bits. Similarly, some uses made the harmless error of using 0L instead of 0. Change-Id: I2afea97282803cb311b9321a99bb627520ef5e35 Reviewed-on: https://gerrit.libreoffice.org/38861 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-06-14Use unique_ptr for SwASCIIParser::pItemSetStephan Bergmann
Change-Id: Ib4eb12d9615308568e316cfb96250f1d72d70a06
2017-06-14use ERRCODE_NONE instead of 0Noel Grandin
peeling off a small chunk of my ErrCode strong_int conversion Change-Id: Idc89e8496083beed7608cba705cd981139eb7111 Reviewed-on: https://gerrit.libreoffice.org/38777 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-06replace SVSTREAM_OK with ERRCODE_NONENoel Grandin
since the first is #define'd to the second, and offers no extra value Change-Id: I2c67e09ea3aa5361b8e7dfe7a20858c6ae054450 Reviewed-on: https://gerrit.libreoffice.org/38406 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2024-06-02 10:27:38 +0000