# New Linear Programming Solver (nlpsolver) This extension integrates into LibreOffice Calc and offers new Solver engines to use for optimizing nonlinear programming models. As there is no known upstream source for `nlpsolver/ThirdParty/EvolutionarySolver`, the code is considered internal and can be modified like any other internal code. itle='lo/core Git repository'/>
summaryrefslogtreecommitdiff
path: root/starmath/source/smdetect.hxx
AgeCommit message (Collapse)Author
2019-01-04tdf#42949 Fix IWYU warnings in starmath/inc/*hxx & starmath/source/*hxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: If1a597f4c2241dc1ad5687d81199bbc5745e711f Reviewed-on: https://gerrit.libreoffice.org/65624 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-20starmath: create SmFilterDetect instances with an uno constructorMiklos Vajna
Change-Id: I11ffe5153bc9ea263cde63093544584f01a344d2 Reviewed-on: https://gerrit.libreoffice.org/65464 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2017-12-14No need to keep these whitelisted functions decorated with SAL_CALLStephan Bergmann
The only effect SAL_CALL effectively has on LO-internal code is to change non- static member functions from __thiscall to __cdecl in MSVC (where all other functions are __cdecl by default, anyway). (For 3rd-party code, it could be argued that SAL_CALL is useful on function declarations in the URE stable interface other than non-static member functions, too, in case 3rd-party code uses a compiler switch to change the default calling convention to something other than __cdecl. But loplugin:salcall exempts the URE stable interface, anyway.) One could argue that SAL_CALL, even if today it effectively only affects non- static member functions in MSVC, could be extended in the future to affect more functions on more platforms. However, the current code would already not support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c "loplugin:salcall fix functions" changed FrameControl_createInstance in UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even though its address (in ctl_component_getFacrory, in the same file) is passed to cppuhelper::createSingleFactory as an argument of type cppu::ComponentInstantiation, which is a pointer to SAL_CALL function. Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6 Reviewed-on: https://gerrit.libreoffice.org/46436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-08-03starmath: cleanup includes with iwyuJochen Nitschke
Change-Id: I6de145f8b59d3ebcbc0cb32df3f955c9ee738eeb Reviewed-on: https://gerrit.libreoffice.org/40666 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-01-26Remove dynamic exception specificationsStephan Bergmann
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-19New loplugin:dynexcspec: Add @throws documentation, starmathStephan Bergmann
Change-Id: I1181cd9fd50fc0307c4475abb8c59e3f16bade91
2016-11-18includes should be at the top of the fileNoel Grandin
not randomly scattered through the code found with something like: git ls-files *.cpp | xargs grep -Pzl "(?s){.*#include" Change-Id: I9c242fa4ef99e8677f2800d7ec9f16d16e488351 Reviewed-on: https://gerrit.libreoffice.org/30952 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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
2015-10-12Replace "SAL_OVERRIDE" with "override" in LIBO_INTERNAL_ONLY codeStephan Bergmann
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
2015-07-27inline a bunch of use-once macrosNoel Grandin
no point in having a macro unless it's actually going to reduce the number of lines of code Change-Id: Ic8760d6506cf272d7bd088f7b3b4dcbf288099fc
2015-04-07cppcheck: make ctor with 1 argument explicitTakeshi Abe
Change-Id: I4514ba75140f112d96c06167c2ed6ec0ca9aa87f Reviewed-on: https://gerrit.libreoffice.org/15179 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-03-02tdf#88206 Change uses of cppu::WeakImplHelper* to the variadic variantTakeshi Abe
... in starmath. Change-Id: If414142c7d1356b8dbbf82bed70b908a4d161653 Signed-off-by: Stephan Bergmann <sbergman@redhat.com>