| Age | Commit message (Collapse) | Author |
|---|
|
<https://github.com/llvm/llvm-project/commit/8775947633bf189e1847707932b1015f04640ea0>
"[clang][NFC] Refactor clang::Linkage"
Change-Id: I35e3a3c7e3de29e4f3b9ee8dfc34e39ba2aa1c70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158919
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
<https://github.com/llvm/llvm-project/commit/1acffe81ee9117691812b9bf8747c03354177d15>
"NFC: [clang] Template argument cleanups."
Change-Id: I84bc276c21efcc11643ae7003e0fee6c7592130f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141860
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I254e1b69f66b985d66c9ce3707614c3b505f2335
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101975
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>
|
|
...to fix false clang-cl warnings like
> C:/lo-clang/core/cppuhelper/source/compat.cxx(113,29): error: externally available entity 'ClassData' is not previously declared in an included file (if it is only used in this translation unit, put it in an unnamed namespace; otherwise, provide a declaration of it in an included file) [loplugin:external]
> struct SAL_DLLPUBLIC_EXPORT ClassData {
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
Change-Id: Iacf96569e27772aa9e27221619516b1fb84dd665
Reviewed-on: https://gerrit.libreoffice.org/84514
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Errors were:
/home/chris/repos/libreoffice-latest/compilerplugins/clang/sharedvisitor/analyzer.cxx:80:40: error: reference to 'PointerType' is ambiguous
if (auto const t = type->getAs<PointerType>())
/home/chris/repos/libreoffice-latest/compilerplugins/clang/external.cxx:61:44: error: reference to 'PointerType' is ambiguous
else if (auto const t3 = t1->getAs<PointerType>())
Change-Id: Ia5b7add8f2b3160fa3198ed127785bdd61c74796
Reviewed-on: https://gerrit.libreoffice.org/83030
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I35c0930f6ab8ae5d96e433958cf29791c78d5e31
Reviewed-on: https://gerrit.libreoffice.org/82802
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...into an unnamed namespace. (And make it into a "leading comment" that
precedes the code it appeartains to. It had orignally been meant as a "trailing
comment" that follows the code it appeartains to, and had been idented further
to indicate that, but clang-format unhelpfully breaks such indentation of
trailing comments that need to be preceded by a line break due to line length
limitations.)
Change-Id: I6a71a6b8e11ba641acfb542142fe14b4b6445f51
Reviewed-on: https://gerrit.libreoffice.org/82792
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...not just those that came before
Change-Id: Ib10ca34cb2ee63124999d56bb00d94f000f33ea1
Reviewed-on: https://gerrit.libreoffice.org/82782
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie283a4774564f25e0fde8ca35212f92be786d671
Reviewed-on: https://gerrit.libreoffice.org/75785
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: Ib27908cba00ca120b3bd2ea1dc291c29120a27a4
Reviewed-on: https://gerrit.libreoffice.org/63705
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Including:
* expanding STDAPI to its definition (as per
<https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add
__declspec(dllexport) into its middle, in
extensions/source/activex/so_activex.cxx; as discussed in the comments at
<https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in
setup_native, use __declspec(dllexport)", having a function both listed in a
.def file EXPORTS and marking it dllexport is OK, and the latter helps the
heuristics of loplugin:external; however, the relevant functions in
extensions/source/activex/so_activex.cxx probably don't even need to be
exported in the first place?
* follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx
Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191
Reviewed-on: https://gerrit.libreoffice.org/60938
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
