...but only in those parts of registry B that are not also in registry A. That
way, we can detect newly introduced violations while ignoring the old
(published) violations for backwards compatibility.
Change-Id: Ifb8ea98fffca29647aa6677a5ade86e5b194ddee
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
It's not very efficient, because we generally end up copying it twice -
once into the parameter and again into the destination OUString.
So I create a clang plugin that finds such places and generates a
warning so that we can convert them to pass-by-reference.
Change-Id: I5341a6ea9e3190f4b4c05c42c85595e3dcd83361
Fixes:
no match for ‘operator!=’ in ‘i != std::vector<_Tp, _Alloc>::rend() [with _Tp = rtl::OUString, _Alloc = std::allocator<rtl::OUString>]()’
Change-Id: I7b4ba07ebe51c73893a3d6b77dcf5681b7638efb
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Otherwise cppuhelper::TypeManager::createTypeDescriptionEnumeration, sitting on
top such an AggregatingCursor, will miss any entities from provider P' in module
M if any previous provider P contains the same module M.
That happened when climaker generates cli_oootypes.dll, where the enumeration
missed everything from offapi in top-level module "com" because it had already
seen udkapi's "com", and only reported the handful of entities under offapi's
other top-level module "org" (which does not appear in udkapi).
Change-Id: If538391bde22bcc346417b5988cf12023f0d4172
...as there are many cases where the code later wants to obtain this part, and
esp. for the string literal variants it is awkward to calculate the length of
the literal again if this is coded with a following copy() call. Adapt some
code to use this new feature.
(Strictly speaking, the @since tags for the---backwards-compatibly---modified
functions are no longer accurate of course. Also, clean up some sal_Bool and
SAL_THROWS(()) that are unnecesssary cargo-cult here, and where the clean-up
should have no practical compatibility consequences.)
Change-Id: I43e5c578c8c4b44cb47fd08f170b5c69322ad641
...for checking compatibility with the reference rdbs. unoidl-check is no
longer based on the legacy registry format, but can process all the various new
UNOIDL registry formats. regcompare is still included in the SDK for now.
(gb_UnoApi[Target]_set_reference_rdbfile now takes a non-empty sequence of rdb
files, any necessary dependencies of the final rdf file preceding it just like
it is required on the unoidl-check command line. Also, executing the
unoidl-check now properly depends on those rdb files.)
TODO: unoidl-check is too conservative for now and flags some changes as
incompatible that are not.
Change-Id: I92e4c69403c5e3fcb31707c98c65a2f509592dd4
The Bison 3 generated sources do not seem to define YYID, so our
YYLLOC_DEFAULT definition was broken. No idea what any of this means,
but sberg said I can safely remove the YYID usage, so if it kills your
pet, you know whom to blame.
Change-Id: I464564be941e0a49da264057923bf8e8e82d5ffd
