Change lowercase ß U+00DF LATIN SMALL LETTER SHARP S from
LowerToUpper, ToUpper: SS
ToTitle: Ss
FullFolding: ss
to
LowerToUpper, ToUpper: ẞ U+1E9E
ToTitle: ẞ U+1E9E
FullFolding: ss
Add uppercase ẞ U+1E9E LATIN CAPITAL LETTER SHARP S
UpperToLower, ToLower: ß U+00DF
FullFolding: ss
Adjust BASIC Collection test to new reality.
Change-Id: I198e06985b81a71e5de94bf7fab7a0dbaf10baef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124988
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Watching a variable which returns a value from a function always shows
"out of scope" in the watch window of the Basic IDE. In order to resolve
this issue, the name of the variable being watched will be searched also
in the current method instance.
Change-Id: I5ff6ce22067e11d74275eeb82da814da1eebe3db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124239
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Watching a variable which returns a value from a function always shows
"out of scope" in the watch window of the Basic IDE. In order to resolve
this issue, the name of the variable being watched will be searched also
in the current method instance.
Change-Id: Id383e03925956056931d199fe86d1b352cf8e4eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124075
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
If a name is ending with an underscore at the end of the line, it won't
be recognized correctly and it will be wrongly interpreted as the
respective name without the underscore at the end. Instead of changing
the macro source, use a flag in order to correclty identify the line end.
Change-Id: I6f933d7382b510bffed3e2692d32c232b7084624
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123833
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
In addition, create a meaningful error message and don't create and
artificial error message if there exists a custom one.
Change-Id: I682e497ee3fdfe4da80fb17ab41c1b4cf90eb2cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122206
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Don't assign a missing optional variable to a property and don't allow
the computation/comparision including missing optional attributes.
In the previous cases a ERRCODE_BASIC_NOT_OPTIONAL is raised.
Change-Id: Iab391286fcace16c271ae511304075e2a0c5c651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121794
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
noting that XMLTokenEnum was already being treated as being limited to
32-bits, we bitmask it together with namespaces
Change-Id: Ic48f2a662452d1b8e022078d31a723d2ac65aef0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121707
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...as it triggers the "rtl_uString_newFromLiteral - Found embedded \0 character"
SAL_WARN in rtl::str::newFromLiteral (called from OUString::createFromAscii via
rtl_uString_newFromLiteral)
Change-Id: I6013062b961657561d67d8dbbf5b2a45816eed4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121086
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Noel Grandin