/embedserv/

88/cgit/lo/core/commit/?id=f23aa1a51cb1beea4ebe3a61ba0c9b3abd844fd9'/> f23aa1a51cb1beea4ebe3a61ba0c9b3abd844fd9 ...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>
...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>
Linkage::ModuleLinkage was only introduced in Clang 5 2018-11-21T12:58:12+00:00 Stephan Bergmann sbergman@redhat.com 2018-11-21T11:03:15+00:00 7fb708ed9fa4f1586887f9b3b541330aa17bbeae Change-Id: Ib27908cba00ca120b3bd2ea1dc291c29120a27a4 Reviewed-on: https://gerrit.libreoffice.org/63705 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>
loplugin:external (clang-cl) 2018-09-24T15:22:05+00:00 Stephan Bergmann sbergman@redhat.com 2018-09-24T13:41:53+00:00 928b1b04adc1cd49cc5d00069084e03675a320f3 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>
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>
New loplugin:external 2018-09-17T07:05:38+00:00 Stephan Bergmann sbergman@redhat.com 2018-09-15T17:13:19+00:00 206b5b2661be37efdff3c6aedb6f248c4636be79 ...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>
...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>