For hex/octal literals take into account trailing suffix types
from GetSuffixType in basic/source/comp/scanner.cxx.
The suffix type $ (String) is not allowed for numeric values
or hex/octal literals and leads to a syntax error
(ERRCODE_BASIC_SYNTAX) during compile time.
Change-Id: Id6c4bbf1296361879f7dec461a48bbdc5c683338
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90978
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Initialize default values of optionals in function headers.
In LO Basic, optional parameters are allowed, but without
any default values. Missing parameters will not be initialized
to their respective default values of its datatype, either.
With option Compatible, optional parameters are allowed
with default values. Missing optional parameters that
don't have explicit default values will not be initialized
to their default values of its datatype.
With option VBASupport, optional parameters are allowed with
default values. Missing optional parameters that don't have
explicit default values will be initialized to their default
values of its datatype.
Change-Id: I57aabae5f70d1cf6c4e8feb95ce0db6af753383c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87550
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I325149be2ea7697b5b4a2ce4a662edd2f8be6e50
Reviewed-on: https://gerrit.libreoffice.org/82312
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
look for OUStringBuffer append sequences that can be turned
into creating an OUString with + operations
Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6
Reviewed-on: https://gerrit.libreoffice.org/80809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
If the value of the hex string lies within the range of 0x8000
(SbxMAXINT + 1) and 0xFFFF (SbxMAXUINT) inclusive, cast the value to 16 bit
in order to get signed integers, e.g., SbxMININT through SbxMAXINT.
Moved unit test to test_scanner.cxx in order to test basic hex
convertations. Removed old vba unit tests.
Change-Id: I247b41c40197afc5328ef5685c758c1dd1cefae5
Reviewed-on: https://gerrit.libreoffice.org/79583
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...at least some of which have presumably been missing from
ce43d0ae9279edbf1ad108fe0d8325327a038d49 "use consistent #define checks for the
Windows platform" by accident (and some just clean up comments)
Change-Id: I5532685c7df96ae3c8a25b73d8064d7433964a9b
Reviewed-on: https://gerrit.libreoffice.org/68580
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I20b38196ee1b6a34384dc46d9de1b6e1b44947ae
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b)
it was expected to gradually remove SAL_U/W usage in Windows code
by replacing with reinterpret_cast or changing to some bettertypes.
But as it's useful to make use of fact that LibreOffice and Windows
use compatible representation of strings, this commit puts these
functions to a better-suited o3tl, and recommends that the functions
be consistently used throughout Windows-specific code to reflect the
compatibility and keep the casts safe.
Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6
Reviewed-on: https://gerrit.libreoffice.org/43150
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This is type-safe, and allows to catch cases where a source type
is changed for some reason, but reinterpret_cast masks that
Change-Id: Ib64b6fa2e22d94a6bba890f0ccc3e20325c6f0a1
Reviewed-on: https://gerrit.libreoffice.org/42961
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* 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:⭐:resource::OfficeResourceLoader
com::sun:⭐:resource::XResourceBundleLoader
com::sun:⭐:resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
... making its value CRLF on Windows and LF on others.
A winding road of regressions passed through it;
first b680e352546dc614f3b30bbe212e6b415a6a6bf4,
then 7beeced463648fc67defea2ad48d58dd42f0ca1e.
Change-Id: I9e4da4a17436949b4fea35481b8355b4321cb268
Reviewed-on: https://gerrit.libreoffice.org/37500
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
