after commit dc21a49ea3a5a655e6bf70860b1b99c20e5b7473
"convert SbxDecimal::CmpResult to scoped enum"
Change-Id: I874976a30a57589cabd37f659a48a81933d867a7
New compiler changes quite some stuff:
* Compiler detection done based on different registry key
* .NET SDK detection done based on different registry key
* Msbuild installation directory changed
* Merge modules installation directory changed
* SDK number in registry doesn't match the directory name:
(registry key: 10.0.14393, directory name: 10.0.14393.0)
* Compiler, include and library location directories changed
* Architecture specific directory changed: x64 instead of amd64
* Compiler own include directory must be added with -I option
* To force usage of SDK 10 (8.1 is selected per default) new
switch WindowsTargetPlatformVersion is passed to msbuild, to
avoid patching VC project files with this line:
<WindowsTargetPlatformVersion><SDK>/WindowsTargetPlatformVersion>
Known issues:
* Firebird is broken: http://paste.openstack.org/show/594333
Change-Id: I148d7932aff43bbbd07bd493504df974726234c2
Reviewed-on: https://gerrit.libreoffice.org/31279
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
...ever since 79d3bc479950127ecfd40f73978c0fc84c1e7908 "INTEGRATION: CWS
visibility03: #i45006# Moved from svtools/source/sbx/", at least
Change-Id: If39462e5907817d6a77c98b212d5031610716a7c
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>
This reverts commit b5e3f8a5fa98a249ecd50021c33cf2a5c7a3b4fc.
The problem is this:
==24217== Conditional jump or move depends on uninitialised value(s)
==24217== at 0x29A25FCE: SfxObjectShell::SetError(unsigned int, rtl::OUString const&) (objmisc.cxx:220)
==24217== by 0x29A35E6E: SfxObjectShell::ImportFrom(SfxMedium&, com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> const&) (objstor.cxx:2300)
==24217== by 0x29A3705C: SfxObjectShell::DoLoad(SfxMedium*) (objstor.cxx:765)
==24217== by 0x29A6BC48:
SfxBaseModel::load(com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) (sfxbasemodel.cxx:1802)
The commit is bogus because it introduces a
DynamicErrorInfo::GetErrorCode(), which overloads
ErrorInfo::GetErrorCode(), which is used at least in
DynamicErrorInfo_Impl::RegisterEDcr() and used to return a constructor
argument of DynamicErrorInfo but now returns pImpl->lErrId,
which is what this statement is trying to initialize.
Ultimately this causes my clang+ASAN build to fail because the
uninitialized error code happens to be detected as a mere Warning:
Test name: testMathMalformedXml::Import
assertion failed
- Expression: !xComponent.is()
- loading succeeded: sw/qa/extras/ooxmlimport/data/math-malformed_xml.docx
Change-Id: I9141144e0bc356ee54279948f2fce036d1831a86
I can see why you'd want to hide this horrible tunnelling of
information with objects registering themselves in a global list.
Urrgh.
Change-Id: Ib151a0d2d5a4508dc456e52883e488ce56d9a095
Reviewed-on: https://gerrit.libreoffice.org/33984
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit fce604c8ae11b462113305aba080d77f8193cfea,
and fixes
tdf#105735 - xray ThisComponent no longer works
in the process.
It turns out Basic doesn't support sal_uInt64 very well, so lets rather
have a small possibility of bad timestamps instead of broken scripts.
Change-Id: Ic00485bd517a4fc61e05632001c9a5f92e05ddd6
Reviewed-on: https://gerrit.libreoffice.org/33972
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...and remove some unncessary using directives/declarations, in preparation of
removing now-unnecessary #includes from cppumaker-generated files, post
e57ca02849c3d87142ff5ff9099a212e72b8139c "Remove dynamic exception
specifications".
Change-Id: Iaf1f268871e2ee1d1c76cf90f03557527ebc9067
fixes this bt:
3 0x00002aaaab314ef2 in __GI___assert_fail (assertion=assertion@entry=0x2aaaaf8dc448 "index >= 0 && static_cast<sal_uInt32>(index) < static_cast<sal_uInt32>(getLength())",
file=file@entry=0x2aaaaf8ac488 "/home/julien/lo/libreoffice/include/rtl/ustring.hxx", line=line@entry=678,
function=function@entry=0x2aaaaf8dc800 <rtl::OUString::operator[](int) const::__PRETTY_FUNCTION__> "sal_Unicode rtl::OUString::operator[](sal_Int32) const")
at assert.c:101
4 0x00002aaaaf810383 in rtl::OUString::operator[] (this=this@entry=0x55555d39c9f8, index=index@entry=0) at /home/julien/lo/libreoffice/include/rtl/ustring.hxx:678
5 0x00002aaaaf822f4e in SbiScanner::NextSym (this=0x55555d39c9d0) at /home/julien/lo/libreoffice/basic/source/comp/scanner.cxx:572
6 0x00002aaaaf82771e in SbiTokenizer::Next (this=this@entry=0x55555d39c9d0) at /home/julien/lo/libreoffice/basic/source/comp/token.cxx:339
7 0x00002aaaaf827d23 in SbiTokenizer::Peek (this=0x55555d39c9d0) at /home/julien/lo/libreoffice/basic/source/comp/token.cxx:266
8 0x00002aaaaf8175d0 in SbiExpression::Unary (this=this@entry=0x55555d43cea0) at /home/julien/lo/libreoffice/basic/source/comp/exprtree.cxx:581
9 0x00002aaaaf8178a4 in SbiExpression::Exp (this=this@entry=0x55555d43cea0) at /home/julien/lo/libreoffice/basic/source/comp/exprtree.cxx:633
10 0x00002aaaaf81792c in SbiExpression::MulDiv (this=this@entry=0x55555d43cea0) at /home/julien/lo/libreoffice/basic/source/comp/exprtree.cxx:647
11 0x00002aaaaf8179b6 in SbiExpression::IntDiv (this=this@entry=0x55555d43cea0) at /home/julien/lo/libreoffice/basic/source/comp/exprtree.cxx:666
Change-Id: Ib56063b3106bd077cda215e34ab763bae1f33c33
Reviewed-on: https://gerrit.libreoffice.org/33933
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...(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>
This reverts commit 93a8ebac2d6eb124bf57223069765af08fcd5c85, now that
fce604c8ae11b462113305aba080d77f8193cfea "[API CHANGE] return unsigned 64-bit
value from GetSystemTicks in basic code" is in.
instead of 32-bit value.
looks like this has been incorrect since
commit 9f2104e1f3a1ef8a37406b39188234df309241bc
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date: Mon Jun 19 16:46:13 2006 +0000
INTEGRATION: CWS warnings01 (1.23.26); FILE MERGED
but nobody cared, since the values would previously fit into a 32-bit
number.
Change-Id: I4c121085977b5e7ff3e33c8ad57749b925ad31b9
Reviewed-on: https://gerrit.libreoffice.org/32879
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Introduced with 060c2b9b1b0d3c9cf27f1b289a620cfa82b5b060 "QA Basic: split tests
of methods in different files", but GetSystemTicks appears to routinely return
negative values.
Change-Id: Ibccdf753aea581e05e9d4e1bf551ae72dc70c959
On Windows x64 there are two ODBCs - one for each bitness.
A 64-bit build gets 64-bit ODBC, and there is no provider named
"Microsoft Excel Driver (*.xls)", no normally the test is simply
skipped. But if MS Excel is installed, then it installs provider
"Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)", that was
detected by previous code, but not used inside the VBAs. So, VBAs
tried to use "Microsoft Excel Driver (*.xls)" unavailable to them.
This patch allows using Excel's provider as well, thus allowing
developer to test against 64-bit-specific regressions.
However, the last test uses Microsoft.Jet.OLEDB.4.0 provider,
that is unavailable on Win64. There are substitutions -
Microsoft.ACE.OLEDB.12.0 and Microsoft.ACE.OLEDB.15.0,
but there is no easy way to test if they are installed. Thus,
that test is disabled on Win64 for now.
Also, possible buffer overflow fixed, when byte count was passed
to SQLGetInstalledDriversW instead of char count.
Change-Id: Ib5c55251f0e92b3078a46aee173b5061439445ae
Reviewed-on: https://gerrit.libreoffice.org/32019
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Notes
(*) In SC, BULK_DATACHANGED was or'ed into the hint id. Replaced with a
dynamic_cast check.
(*) In SC, removed the hint id field from ScIndexHint, no point in
storing the hint id twice
(*) Fold the SfxStyleSheetHintId enum into the new SfxHintId enum, no
point in storing two different hint ids
(*) In some cases, multiple #define's used to map to the same SFX_HINT
value (notably the SFX_HINT_USER* values). I made all of those separate
values.
Change-Id: I990e2fb587335ebc51c9005588c6a44f768d9de5
Reviewed-on: https://gerrit.libreoffice.org/31751
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
