Age | Commit message (Collapse) | Author |
|
...as discussed at
<https://lists.freedesktop.org/archives/libreoffice/2018-November/081435.html>
"minutes of ESC call ..."
Change-Id: Ia053da171d59747984546f38e19da808825b4f79
Reviewed-on: https://gerrit.libreoffice.org/63832
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
by checking if the current namespace decl is in our code, so we have to
scan less stuff, which results in a 10% perf improvement for me
Change-Id: Idf0e30d57b6d0dcd13daa9ed679c28b9d233d387
Reviewed-on: https://gerrit.libreoffice.org/58942
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which first added alternative names to and then deprecated getLocBegin/End
Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2
Reviewed-on: https://gerrit.libreoffice.org/58820
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
There are some problems here, this should fix one of them: the
getFilename function returns "<stdin>" for spelling locations, because
the input to clang is sort of preprocessed via -frewrite-includes if
icecream is used and the file is built on a remote host (whereas it's
apparently not preprocessed if the file is compiled locally by icecream).
Using getPresumedLoc() uses the #line directives in the preprocessed
input, which avoids the problem but is more expensive, so try to use it
only when necessary.
The getFileEntry(getMainFileID())->getName() pattern will also result
in "<stdin>", but fortunately icecream passes -main-file-name,
which oddly enough isn't used by the SourceManager's spelling locations,
but is available separately via CodeGenOptions.
This builds everything successfully with clang version 6.0.0:
ICECC_PREFERRED_HOST=myremote make check gb_SUPPRESS_TESTS=t
Change-Id: Ic121511683e5302d7b9d85186c8b9c4a5443fa1b
Reviewed-on: https://gerrit.libreoffice.org/54993
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
<https://lists.freedesktop.org/archives/libreoffice/2017-December/079107.html>
"Clang baseline bump"
Change-Id: I18fca8794ea34118fc6308458064d0c28cf5caf7
Reviewed-on: https://gerrit.libreoffice.org/46557
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I26734c13515394162d88351a1cbe2b20abdac865
|
|
Change-Id: I21133976793ab018c633dda077029666308526db
|
|
Change-Id: I91bc89a9076c6642e06b238f65f2d31a1d20c6b5
|
|
Change-Id: I5b4523929f971d0345f112ba4f5faff1181cee2b
|
|
Change-Id: I1b8a3dfa1dc6b351ab0903a74eae19dfa6d0888d
|
|
sal_Bool and sal_uInt8 are typedefs for the same underlying type, so any use of
ORowSetValue with sal_Bool instead of bool, apparently intending to treat the
value as a boolean, actually treated it as a TINYINT. (See e.g. recent
7b0c57b2faec875c790051d233d1e9abaed2a3bc "some compilers don't like implicit
bool-to-ORowSetValue conversion".)
Now that there's no way to create a sal_uInt8 ORowSetValue, getUInt8 and the
m_uInt8 union member can probably go away, too.
Change-Id: Ia27554f76e7e9edce6410284b578064573e54fd3
Reviewed-on: https://gerrit.libreoffice.org/31909
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If470e1d9b481c9eda0829aa985152baf8fb46d7a
|
|
Change-Id: I8374d6d08f4eb4ae2821e213371c615b92d7e9ab
Reviewed-on: https://gerrit.libreoffice.org/29432
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I09c9c57d5adeb665cc2508fad9727085a3289bfb
|
|
Change-Id: I81e97c5f720535b33dd3ce72d01151765e4e93a0
|
|
Change-Id: I185852a738bac10dc6d331afccfcbc7ae1225cb1
|
|
Change-Id: I7cb43f915565dadd611b90ee30373e472f97efb5
Reviewed-on: https://gerrit.libreoffice.org/26748
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I67eac95686678e6f5a2d60798535b2c65a9ba5d7
|
|
Change-Id: I3c5bf7a53c9ae173f8fce885ecf022f092aa43a9
|
|
"SourceManager::isMacroArgExpansion has only one param in older Clang", which
caused false positives like warning about sal_False in
CPPUNIT_ASSERT_EQUAL(guard.p->m1, sal_False);
in cppu/qa/cppumaker/test_cppumaker.cxx
Change-Id: I1c5a67527aef381e336d71cb8fefbb87961bbf96
|
|
Change-Id: I5aa4f7cca70b8196263613b92c018323152411a1
|
|
...that can generally be rewritten as false/true, and sometimes could hide
errors, see e.g. <5be5f00fe16b0e255b31fbaba5f119773d1cd071> "So this is
apparently about right-to-left levels, not a boolean flag".
Change-Id: Ib39a936a632c2aab206f24c346252e31dcbb98f3
|
|
Change-Id: I9d5b14c374ce62ac7b970faa30c38a5a76568ed4
|
|
Change-Id: I1730c09669426e049aba941ef27341581ce31887
|
|
...not the (Clang) compiler they are being built /with/. (Also simplifies the
checking #if code.)
Change-Id: I416321be4ef4478785be40571f81500fd3b6feb8
|
|
Change-Id: I3b845ae46b0d0b14be90382727cc02a838a0392e
|
|
Change-Id: I745b320dd5f44d54371d8a0b961c49793e3e0ad6
|
|
Change-Id: I5b41039bf63a4c2f313fe7a57c0f6934dcb0752d
|
|
...and is apparently a leftover from temporary debug output in
e36badb98d0bb5866a297cb51c3e95cdce62d8da "Fix workaround for bug in Clang 3.2
FunctionDecl::isInlined."
Change-Id: I3213981c5d236a7b67083014692566f75a2bcd51
|
|
Change-Id: If9d85236177c819c159d1b836e806fc2b03da45c
|
|
Change-Id: I9b0b6affc60ae030b644fdd13eecfb1aed1f472a
|
|
Change-Id: I214a9745f27c27868b3e74785cf7138fc1db1943
|
|
Change-Id: Ibf1d8c74dc8abb8c1fef59c53a8873cc426e2932
|
|
Change-Id: I45b323b326cc56cfc48e0abaa52d51fd86adbf79
|
|
Change-Id: I2746abd05edd00dadfe613c17b9874b1035c3be4
|
|
Change-Id: Ib1f33387c50bcd853140eb2fc46995d23d7f367b
|
|
Change-Id: I63d00cf5ab1dac953fae07ca4eb4d987610551a2
|
|
Change-Id: I78a368ef2899b2462251b45a327fc7b1f31fe764
|