Skip to content

C
core
Dal (branch)/etiket değiştir
  1. 08 Eki, 2018 1 kayıt (commit)
  3. 17 Eyl, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      New loplugin:external · 206b5b26
      Stephan Bergmann yazdı 
      ...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: 's avatarStephan Bergmann <sbergman@redhat.com>
      206b5b26
  5. 07 Eyl, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      DeInitVCL in PythonTest · e7a3329f
      Stephan Bergmann yazdı 
      After b9757f5c "loplugin:useuniqueptr in
vcl/svdata" ASan/UBSan builds started to fail (like
<https://ci.libreoffice.org//job/lo_ubsan/1025/>) at the end of
PythonTest_dbaccess_python (and probably other PythonTests), when during exit
the static utl::ConfigManager instance already happens to be destroyed by the
time the static ImplSVData's mpSettingsConfigItem is destroyed (which would
normally be cleared during DeInitVCL, if PythonTests would call that, and which
in the past had thus simply been leaked in PythonTests when that
mpSettingsConfigItem was a plain pointer instead of std::unique_ptr).

So ensure that PythonTests that initialize VCL also call DeInitVCL, via a new
private_deinitTestEnvironment, complementing the existing
private_initTestEnvironment.

However, while private_initTestEnvironment is called once (typically via
UnoInProcess.setUp, which internally makes sure to only call it once) as soon as
the first executed test needs it, private_deinitTestEnvironment must be called
once after the lasts test needing it has executed.  The only way that I found to
do that is to override unittest.TextTestResult's stopTestRun method, which is
called once after all tests have been executed.  Hence a new test runner setup
in unotest/source/python/org/libreoffice/unittest.py that is now called from
solenv/gbuild/PythonTest.mk.

That revealed a few places in PythonTests that didn't yet close/delete documents
that they had opened, which has now been added.

One remaining problem then is that classes like SwXTextDocument and friends call
Application::GetSolarMutex from their dtors, via sw::UnoImplPtrDeleter (a "Smart
pointer class ensuring that the pointed object is deleted with a locked
SolarMutex", sw/inc/unobaseclass.hxx).  That means that any PyUNO proxies to
such C++ objects that remain alive after private_deinitTestEnvironment will
cause issues at exit, when Python does a final garbage collection of those
objects.  The ultimate fix will be to remove that unhelpful UnoImplPtrDeleter
and its locking of SolarMutex from the dtors of UNO objects; until then, the
Python code is now sprinkled with some HACKs to make sure all those PyUNO
proxies are released in a timely fashion (see the comment in
unotest/source/python/org/libreoffice/unittest.py for details).  (Also, it would
probably help if UnoInProcess didn't keep a local self.xDoc around referencing
(just) the last result of calling one of its open* methods, confusingly making
it the responsibility of UnoInProcess to close that one document while making it
the responsibility of the test code making the other UnoInProcess.open* calls to
close any other documents.)

Change-Id: Ief27c81e2b763e9be20cbf3234b68924315f13be
Reviewed-on: https://gerrit.libreoffice.org/60100
Tested-by: Jenkins
Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      e7a3329f
  7. 29 Tem, 2018 1 kayıt (commit)
  9. 27 Tem, 2018 1 kayıt (commit)
  11. 29 Haz, 2018 1 kayıt (commit)
  13. 05 May, 2018 1 kayıt (commit)
  15. 14 Nis, 2018 1 kayıt (commit)
  17. 06 Nis, 2018 1 kayıt (commit)
  19. 03 Nis, 2018 1 kayıt (commit)
  21. 11 Ara, 2017 1 kayıt (commit)
  23. 20 Kas, 2017 1 kayıt (commit)
  25. 23 Eki, 2017 1 kayıt (commit)
  27. 07 Eyl, 2017 1 kayıt (commit)
  29. 24 Agu, 2017 1 kayıt (commit)
  31. 22 Agu, 2017 1 kayıt (commit)
  33. 27 May, 2017 1 kayıt (commit)
  35. 07 May, 2017 1 kayıt (commit)
  37. 06 May, 2017 1 kayıt (commit)
  39. 28 Nis, 2017 1 kayıt (commit)
  41. 21 Nis, 2017 1 kayıt (commit)
  43. 13 Mar, 2017 1 kayıt (commit)
  45. 11 Mar, 2017 1 kayıt (commit)
  47. 02 Mar, 2017 1 kayıt (commit)
  49. 12 Şub, 2017 1 kayıt (commit)
  51. 17 Ock, 2017 1 kayıt (commit)
  53. 01 Ara, 2016 1 kayıt (commit)
  55. 26 Kas, 2016 1 kayıt (commit)
  57. 21 Kas, 2016 1 kayıt (commit)
  59. 26 Eki, 2016 1 kayıt (commit)
  61. 13 Eyl, 2016 1 kayıt (commit)
    • Stephan Bergmann's avatar
      loplugin:override: No more need for the "MSVC dtor override" workaround · 91dd2db1
      Stephan Bergmann yazdı 
      The issue of 362d4f0c "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.

(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to

  OOO_DLLPUBLIC_CHARTTOOLS    virtual ~CloseableLifeTimeManager();

in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro.  Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)

Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
      91dd2db1
  63. 16 May, 2016 1 kayıt (commit)
  65. 13 Nis, 2016 1 kayıt (commit)
  67. 12 Nis, 2016 1 kayıt (commit)
  69. 02 Nis, 2016 1 kayıt (commit)
  71. 10 Mar, 2016 2 kayıt (commit)
  73. 10 Ock, 2016 1 kayıt (commit)
  75. 05 Ock, 2016 1 kayıt (commit)
  77. 10 Kas, 2015 1 kayıt (commit)