| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I6dde54ddc2a2be4a9bbe11cdb52550de7f6a1023
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97836
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic8a3d07ec6ec5a5d6d56a3958e91d3074ce1493e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96936
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97788
Tested-by: Jenkins
|
|
...now also covering variables with internal linkage that don't need a redundant
"static". (Unlike with functions, with variables there are also cases that are
not in an unnamed namespace, hence the rename of the plugin.)
All the relevant changes across the code base have been done in the preceding
"Upcoming improved loplugin:staticanonymous -> redundantstatic" commits.
Ideally the changes would have been done with a rewriting plugin, but it can be
quite tedious in general to identify the correct occurrence of "static" that
must be removed, consider e.g.
struct { int init() { static int n; return n++; } int x = init(); } static
const a[10] = {};
However, it turned out that in all cases across the code base, the relevant
"static" was either at the start of the declaration or came after an initial
"const". So I temporarily changed the plugin with
> --- a/compilerplugins/clang/redundantstatic.cxx
> +++ b/compilerplugins/clang/redundantstatic.cxx
> @@ -59,7 +59,7 @@ class RedundantStatic
> }
> report(
> DiagnosticsEngine::Warning, "redundant 'static' keyword in unnamed namespace",
> - decl->getLocation())
> + decl->getBeginLoc())
> << decl->getSourceRange();
> return true;
> }
> @@ -73,7 +73,7 @@ class RedundantStatic
> DiagnosticsEngine::Warning,
> "non-inline variable of non-volatile const-qualified type is redundantly marked as"
> " 'static'",
> - decl->getLocation())
> + decl->getBeginLoc())
> << decl->getSourceRange();
> return true;
> }
to report the diagnostics at the start of the declarations (instead of at a more
natural place which is typically somewhere in the middle of the declaration),
compiled LO from within Emacs and then ran a function
> (defun doit ()
> (interactive)
> (while t
> (next-error)
> (with-current-buffer (window-buffer)
> (when (re-search-forward
> "\\=\\(\\<static\\>\\s *\\|\\(\\<const\\>\\)\\s +\\<static\\>\\)"
> nil t)
> (replace-match "\\2")))))
to do all the replacements. (Plus solenv/clang-format/reformat-formatted-files
where necessary.)
Change-Id: Ie7efc8e0593a407c390a6a7a08c81e547410f18a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97779
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...so drop the former. But keep the relevant externvar tests by moving them
into compilerplugins/clang/test/external.cxx. (Which revealed one difference
between the two plugins, regarding certain extern "C" variables in unnamed
namespaces, where Clang (and for that matter also e.g. GCC, it appears)
deliberately deviates from the Standard and considers them to have external
linkage. Add clarifying comments that loplugin:external keeps considering these
as having internal linkage, following the Standard.)
Change-Id: I344fcd0135fdaf6bf08a4b396af2ed2299389a7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97639
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie9d4761747f7e97f63f34394b5a8b9f0bb287a0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia0f517fba3a0660b64c97f426cc2cdfbbcd0ebad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97391
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4cccac5b6bba55d87361b07b05220ce890e75412
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97390
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I54f0e2864cb4ef00fea8f9e4369a1f76721e7503
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97369
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...by addressing the follow-up TODO mentioned in the commit message of
7a3736f908c0ae207567603c61ce0f617339bac0 "New loplugin:elidestringvar"
(extending it not only to uses with a constant sal_Unicode, but also to uses
with OUStringLiteral).
(All necessary changes have been made in preceding "Upcoming improved
loplugin:elidestringvar" commits.)
Change-Id: Ib0000ef9c4a1dad52124dfd039dd936cf7e3ba3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97226
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idcaaecd5be080e43b731f8edcbbfb8aed5e2e28c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97048
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7d8cd41c6b4b97a6d33764a8580f08413e584a69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib724da1f07be9e8f4d0d505f7f2886990cab661f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97022
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9e38fe570b2296341c1694fe8128da30ba209494
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94184
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94616
Tested-by: Jenkins
|
|
Change-Id: I05ff44b5b9a7981b98a7eb09837fb32f9308116c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94935
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I9fbb2e38632d8baa48fb9325824fd2bf7a064d10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95840
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
rework the "menu" to be a treeview using hover selection instead of
a custom set of widgetry, and drop the newly unused custom a11y code
Change-Id: Ie7d9b7875ce00843b3f262882816cebb472bf681
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95223
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I60bcfa3182ce67ab50195ae6e7436839afe62c87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96028
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
limited this only fixing assignments inside "if" statements, since other
things are harder to change
Change-Id: If3188a3e3d5fcd94123211c97fee097ece5e2797
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95990
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/unusedfields.cxx Line 143: variable 'x' is uninitialized when passed as a const reference argument here
and
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/writeonlyvars.cxx Line 93: variable 'm_bar10' is uninitialized when passed as a const reference argument here
since <https://github.com/llvm/llvm-project/commit/
170b6869b563dd3393d99f3e03d389b9058d5f24> " [Clang] Add a new warning to warn
when passing uninitialized variables as const reference parameters to a
function"
Change-Id: I27136e387f7a14fd24a3639187b668d6ed283070
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95994
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
When building the plugins with NDEBUG defined.
Change-Id: If84a920d9e042bf8f45d8e3dd5a5cef3b2baba0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95788
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Quoting compilerplugins/clang/elidestringvar.cxx (and see there for a
rationale): "Find cases where a variable of a string type (at least for now,
only OUString) is initialized with a literal value (incl. as an empty string)
and used only once."
(This commit includes fixes that become necessary in code changed after the
preceding "Upcoming loplugin:elidestringvar" commits.)
As a follow-up TODO, uses of the
explicit OUString( sal_Unicode value )
ctor where value is char or char16_t literal should be detected too, so that
e.g. one_quote would have been treated like two_quote in
4b85108773f9851f358a4daa8869eeadc638d103 "Upcoming loplugin:elidestringvar: sc"
> --- a/sc/source/core/tool/compiler.cxx
> +++ b/sc/source/core/tool/compiler.cxx
> @@ -1902,9 +1902,8 @@ void ScCompiler::CheckTabQuotes( OUString& rString,
> if( bNeedsQuote )
> {
> const OUString one_quote('\'');
> - const OUString two_quote("''");
> // escape embedded quotes
> - rString = rString.replaceAll( one_quote, two_quote );
> + rString = rString.replaceAll( one_quote, "''" );
> }
> break;
> }
Change-Id: I7b74f1735a07540e3d789df1d14c84081c824b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and fix some loplugin:simplifypointertobool warnings
Change-Id: I3644c390a3339a4cb8d66d6d034a0f043de9320c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95572
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to look for the
x.get() == null
pattern, which can be simplified to
!x
Change-Id: I0eddf93257ab53ab31949961d7c33ac2dd7288ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95400
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to look for the
x.get() != null
pattern, which can be simplified to
x
I'll do the
x.get() == nullptr
pattern in a separate patch, to reduce the chances of a mistake
Change-Id: I45e0d178e75359857cdf50d712039cb526016555
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In right-to-left paragraph mode, transliterate
Hungarian text word by word during typing, also
add the associated checkbox to Localized Options
page of AutoCorrect dialog window.
Old Hungarian (ISO 15924: Hung) is a historical
and renewed script which is still in use to
transliterate Hungarian writing.
As a localized AutoCorrect feature, the patch supports
the followings:
– word-by-word transliteration of Hungarian texts only
in right-to-left paragraph mode.
– consonant disambiguation of digraphs and trigraphs
based on hyphenation (now pattern-based Huhyphn
dictionary of libhyphen, planned dictionary based
Hunspell later)
– transliteration by extended hu-Hung module of
Numbertext library.
Note: transliteration of the selected text using
AutoCorrect Apply function has't been implemented, yet.
Change-Id: Iee0f18e2485c974c35acf0a3abc3a49c2cf80196
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95303
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
This reverts LO6.4 commit 5cf057c3365a0feafc8f2e4f4a9e24d69a581999,
in order to fix tdf#133158.
This commit is obsolete, but was left in place since it
seemed to have fixed a problem (in =gtk3 anyway).
But now SAL_USE_VCLPLUGIN=gen behaves differently,
so obviously a fix in one place must have broken another.
Better the problems you have always known than
a new problem, especially since this patch
isn't used to fix anything specific in gtk3 anymore
(since those changes were also reverted).
An earlier gerrit version of this revert (which
didn't just have an ignore-this-clang-rule exception)
half-worked, but failed if multiple documents
were opened.
Change-Id: Ie8ddb7b9669fa46067d04c35e157ea08701df0da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95282
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
mostly to catch stuff from the flatten work, but I think this looks good
in general
Change-Id: I7be5b7bcf1f3d9f980c748ba20793965cef957e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92493
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia7870d1d0d91de213727116ccda5b41913223866
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95097
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(*) fix: I was substracting the padding space instead of adding it
when calculating how much free space we had to improve.
(*) sort input data, so we process structs located in the same DSO
together, which reduces GDB's memory usage
(*) handle another error condition, where gdbs output is sufficiently
mixed up that we miss the end of commands terminator
Change-Id: Ic4bb92b736f38a2b3d90e4a14485152b7f869b43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95041
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
in the document, looks like only the calc one actually works, and when
it works on large quantities of results calc grinds to a complete halt
This was introduced with:
commit b41332475783c31136673fb44cf4c411bb0148f8
Date: Mon Dec 2 15:54:29 2013 +0000
Integrate branch of IAccessible2
and has been a problem on and off with calc's potentially ~infinite grid
There is the on-by-default search results dialog in calc (which has a limit on
how many it shows) which provides an alternative route to iterate through the
results
Change-Id: I2685e480d2d15220be0bddbc83baad3992e7d5d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95006
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...as discussed as an open TODO in the commit message of
fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for
libstdc++ std::shared_ptr". The necessary changes across the code base have
been done fully automatically with the rewriting plugin on Linux. (All those
changes apparently involve uses of macro arguments wrapped in parentheses in the
macro body, but always in conditionally-converted-to-bool contexts. In other
contexts, such automatic rewriting would add the "bool" to the macro body, which
would be wrong in general, but we apparently get away with that sloppy coding
for now.)
The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had
introduced to treat such (then-undetected, it had turned out) parenthesized
cases now turns out to not be needed after all.
Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix
loplugin:simplifypointertobool for libstdc++ std::shared_ptr", this time for
uses of oox::drawingml::chart::ModelRef, which derives from std::shared_ptr.
Change-Id: I7e9620da52b3f6d26c6fe6d7909888c3a221c164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94975
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
...since <https://github.com/llvm/llvm-project/commit/
d0da5d2bbe8305d06dc01a98706fd73e11e24a9f> "Change default traversal in AST
Matchers to ignore invisible nodes". This caused failures
> [CPT] compilerplugins/clang/test/constparams.cxx
> ParmVarDecl 0x11d76c730 <compilerplugins/clang/test/constparams.cxx:15:12, col:18> col:18 used f1 'int *'
> DeclRefExpr 0x11d76c948 'int *' lvalue ParmVar 0x11d76c730 'f1' 'int *'
> ParmVarDecl 0x11d76cc80 <compilerplugins/clang/test/constparams.cxx:21:12, col:18> col:18 used f2 'int *'
> DeclRefExpr 0x11d76ce60 'int *' lvalue ParmVar 0x11d76cc80 'f2' 'int *'
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/constparams.cxx Line 15: this parameter can be const Class1::Class1 [loplugin:constparams]
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/constparams.cxx Line 15: no parent? [loplugin:constparams]
> File compilerplugins/clang/test/constparams.cxx Line 21: no parent? [loplugin:constparams]
> 3 errors generated.
[...]
> [CPT] compilerplugins/clang/test/unusedenumconstants.cxx
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/unusedenumconstants.cxx Line 30: read Bottom [loplugin:unusedenumconstants]
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/unusedenumconstants.cxx Line 30: write Bottom [loplugin:unusedenumconstants]
> 2 errors generated.
[...]
> [CPT] compilerplugins/clang/test/unusedfields.cxx
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/unusedfields.cxx Line 156 (directive at compilerplugins/clang/test/unusedfields.cxx:164): write m_f5 [loplugin:unusedfields]
> File compilerplugins/clang/test/unusedfields.cxx Line 210 (directive at compilerplugins/clang/test/unusedfields.cxx:211): read m_f1 [loplugin:unusedfields]
> 2 errors generated.
For compilerplugins/clang/test/constparams.cxx at least it would have worked to
fix that locally with
> diff --git a/compilerplugins/clang/constparams.cxx b/compilerplugins/clang/constparams.cxx
> index 95c8184009d7..70f056fa5a69 100644
> --- a/compilerplugins/clang/constparams.cxx
> +++ b/compilerplugins/clang/constparams.cxx
> @@ -274,7 +274,7 @@ bool ConstParams::checkIfCanBeConst(const Stmt* stmt, const ParmVarDecl* parmVar
> {
> for ( auto cxxCtorInitializer : cxxConstructorDecl->inits())
> {
> - if ( cxxCtorInitializer->getInit() == stmt)
> + if ( cxxCtorInitializer->getInit()->IgnoreImpCasts() == stmt)
> {
> if (cxxCtorInitializer->isAnyMemberInitializer())
> {
(somewhat unintuitively, given the Clang change is apparently about ignoring
more implicit nodes), but overall it appears better---at least for now---to use
a getParents variant that keeps the old traversal behavior.
For that, instead of using the clang::ASTContext::ParentMapCtx, we create our
own loplugin::Plugin::parentMapContext_. There appear to be no uses of
ASTContext::getParent across the Clang codebase itself, outside of ASTMatcher
code, so it looks unlikely that creating our own ParentMapContext instance would
degrade performance by no longer sharing cached data between Clang's internals
and our plugin. (And given that ASTContext::getParents is deprecated with the
note "New callers should use ParentMapContext::getParents() directly", this may
well be the correct way in the long run, anyway.)
Change-Id: I46c7912f2737e7c224fd45ab41441f69e2f10bd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94795
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I235e00eca7b7cbc070bf5831117868eba5c7c273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8961b5df1b3a7ea9b7dd83114fce1555b9e4ffcc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94787
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1af2948e0332044ef88bc7dbd837e8c7afe7af19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94785
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Windows is now more or less the only platform where Skia gets used.
There's also the 'gen' VCL backend on Linux, but that one gets
used rarely and it's Skia options are still accessible in the expert
configuration.
Change-Id: Ibec9b8b15e9200f003367b4568432ce93ec63893
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94708
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
the FreetypeFont only makes sense in the context of the FreetypeFontInstance it
belongs to so remove the faux "garbage collection" and just have FreetypeFontInstance
own the FreetypeFont and keep it simple.
Setting a value low enough to make the garbage collection kick in just crasheed
libreoffice by pulling FreetypeFont out from under living FreetypeFontInstance
seeing as the Cache/Uncache was by the FreeTypeTextRenderImpl not the
FreetypeFontInstance which had HarfBuff faces which continued to point to the
removed FreetypeFont
There is still a cache at the LogicalFontInstance level, so this aligns the
libfreetype platforms with windows, mac etc.
Change-Id: Iac669fae8dc1df81a5bc10d2943d84a2ff623180
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94546
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If179d0a13f3c9f7a49e3efe9027a64368ed600a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94544
Tested-by: Jenkins
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifa90e9721edeacd4fd78fde968b81aab873e2061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94497
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...to 1d0bc2139759f087d50432f8a2116060676f34e1
"use std::experimental::source_location in uno::Exception"
Change-Id: I2b18dbae89c6f219edacba5d147ea265ca83725e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94422
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8796c0937fe4b046d9a13e2e50368e45e0e45611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94404
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I95391ef6ed5154efc2c7705dde22afa59da24a70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94403
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I52187eccf6170f64d38c673a86dc80818813efa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94328
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If0e362cf5b403be63439ec694f3a0e440dfd9bc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94327
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
LogicalFontInstance dtor does call hb_font_destroy though
Change-Id: I59d9711f1934966cddd73c5e62c8929f08b1359a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94335
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibb37c7e840a32453b1d52854d5f958c0285cd26a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94326
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0ec89b56b339f26bb236887c904e6b5d14ceecea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94136
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id813d95a90fdbb360dfc8670c0b55b635f633965
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
