1. 02 Agu, 2018 1 kayıt (commit)
    • Gabor Kelemen's avatar
      Add missing sal/log.hxx headers · 82828c6c
      Gabor Kelemen yazdı
      rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
      This is a continuation of commit 6ff2d84a to be able to remove those unneeded includes.
      
      This commit adds missing headers to every file found by:
      grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
      to directories from test to vbahelper
      
      Change-Id: Ia7f773511624099505d6a36a8d6e23c0cde4a737
      Reviewed-on: https://gerrit.libreoffice.org/58225
      Tested-by: Jenkins
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.co.uk>
      82828c6c
  2. 29 Tem, 2018 1 kayıt (commit)
  3. 27 Tem, 2018 2 kayıt (commit)
    • Noel Grandin's avatar
      new loplugin:stringloop, and applied in various · c8fa03b1
      Noel Grandin yazdı
      look for OUString being appended to in a loop, better to use
      OUStringBuffer to accumulate the results.
      
      Change-Id: Ia36e06e2781a7c546ce9cbad62727aa4c5f10c4b
      Reviewed-on: https://gerrit.libreoffice.org/58092
      Tested-by: Jenkins
      Reviewed-by: 's avatarNoel Grandin <noel.grandin@collabora.co.uk>
      c8fa03b1
    • Stephan Bergmann's avatar
      unotools: avoid -Werror=deprecated-copy (GCC trunk towards GCC 9) · 7f0bdd5e
      Stephan Bergmann yazdı
      ...by explicitly defaulting the copy/move functions (and, where needed in turn,
      also a default ctor) for classes that have a user-declared dtor that does
      nothing other than an implicitly-defined one would do, but needs to be user-
      declared because it is virtual and potentially serves as a key function to
      emit the vtable, or is non-public, etc.; and by removing explicitly user-
      provided functions that do the same as their implicitly-defined counterparts,
      but may prevent implicitly declared copy functions from being defined as non-
      deleted in the future.  (Even if such a user-provided function was declared
      non-inline in an include file, the apparently-used implicitly-defined copy
      functions are already include, so why bother with non-inline functions.)
      
      Change-Id: Iaa08ef916a2d266e011a2cb66592b377cb1eb23c
      Reviewed-on: https://gerrit.libreoffice.org/58095
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      7f0bdd5e
  4. 26 Tem, 2018 1 kayıt (commit)
  5. 11 Tem, 2018 1 kayıt (commit)
    • Noel Grandin's avatar
      clean up UNO available() implementations · 00850e3f
      Noel Grandin yazdı
      There seems to be some confusion here. available() is actually the
      number of bytes that can be read without blocking, but most
      implementations seems to be just returning the number of bytes remaining
      in the stream. Since we're doing that, let's do it properly.
      
      (*) some of them were just casting, instead of clamping, which will
      return wrong values sometimes.
      (*) FileStreamWrapper_Impl/OInputStreamWrapper/OTempFileService were
      doing unnecessary work, instead of just asking the underlying SvStream
      for it's remaining size
      
      Change-Id: I3ef26e0363e989ed3e00be0fdb993e1cdeb7819f
      Reviewed-on: https://gerrit.libreoffice.org/57264
      Tested-by: Jenkins
      Reviewed-by: 's avatarNoel Grandin <noel.grandin@collabora.co.uk>
      00850e3f
  6. 10 Tem, 2018 1 kayıt (commit)
  7. 09 Tem, 2018 1 kayıt (commit)
  8. 28 Haz, 2018 1 kayıt (commit)
  9. 08 Haz, 2018 1 kayıt (commit)
  10. 05 Haz, 2018 1 kayıt (commit)
  11. 30 May, 2018 1 kayıt (commit)
    • Luboš Luňák's avatar
      make CharClass also mutex-protect calls to its dependent class · a2045f94
      Luboš Luňák yazdı
      When calc_tests runs test_tdf53482_Range_contains_column_headings_file()
      with Calc's threading enabled, it ends up calling ScInterpreter::ScProper()
      from threads, which calls to CharClass. And while CharClass tries to be
      thread-safe (guessing from the mutex usage), it forwards calls to i18npool's
      CharacterClassificationImpl and cclass_Unicode, both of which aren't
      thread-safe. Which makes thread safety of CharClass itself pointless.
      
      Since CharClass already acquires the mutex anyway because of getMyLocale(),
      just extend the duration for the entire call, which hopefully shouldn't
      make that much of a difference.
      
      Change-Id: I544b34d7e58c4a901f3b6e3a3ff52156b9e320a8
      Reviewed-on: https://gerrit.libreoffice.org/54999Reviewed-by: 's avatarMichael Meeks <michael.meeks@collabora.com>
      Tested-by: 's avatarLuboš Luňák <l.lunak@collabora.com>
      a2045f94
  12. 28 May, 2018 1 kayıt (commit)
  13. 20 May, 2018 1 kayıt (commit)
  14. 17 May, 2018 2 kayıt (commit)
  15. 11 May, 2018 1 kayıt (commit)
    • Tor Lillqvist's avatar
      Avoid gengal hanging in an --enable-dbgutil build on Windows · 2ff121f2
      Tor Lillqvist yazdı
      With a newer C++ debug runtime (in an --enable-dbgutil build), passing
      an invalid locale name causes an attempt to display an error
      dialog. Which does not even show up, at least for me, but instead the
      process (gengal, at least) just hangs. Which is far from ideal.
      
      Passing a POSIX-style locale name to the std::locale constructor on
      Windows is a bit odd, but apparently in the normal C++ runtime it
      "just" causes an exception to be thrown, that boost catches (see the
      loadable(std::string name) in boost's libs\locale\src\std\std_backend.cpp),
      and then instead uses the Windows style locale name it knows how to
      construct. (Why it even tries the POSIX style name on Windows I can't
      understand.)
      
      Actually it isn't just the locale name part "en_US" of a locale like
      "en_US.UTF-8" that is problematic, but also the encoding part,
      "UTF-8". The Microsoft C/C++ library does not support UTF-8
      locales. The error message that our own report hook catches says:
      "f:\dd\vctools\crt\crtw32\stdcpp\xmbtowc.c(89) : Assertion failed:
      ploc->_Mbcurmax == 1 || ploc->_Mbcurmax == 2". Clearly in a UTF-8
      locale (perhaps one that boost internally constructs?) the maximum
      bytes per character will be more than 2.
      
      With a debug C++ runtime, we need to avoid the error dialog, and just
      ignore the error. So we install an own CRT error report hook that
      ignores the error for the duration of the locale construcion.
      
      Change-Id: Ia2ca994f03d1ce94ce7e9d7607f204c320ab8f2d
      Reviewed-on: https://gerrit.libreoffice.org/54110Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
      2ff121f2
  16. 03 May, 2018 1 kayıt (commit)
  17. 26 Nis, 2018 1 kayıt (commit)
  18. 25 Nis, 2018 2 kayıt (commit)
  19. 11 Nis, 2018 1 kayıt (commit)
  20. 09 Nis, 2018 1 kayıt (commit)
  21. 03 Nis, 2018 1 kayıt (commit)
  22. 02 Nis, 2018 1 kayıt (commit)
  23. 01 Nis, 2018 1 kayıt (commit)
  24. 29 Mar, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Remove bogus assert · d7a8fa7a
      Stephan Bergmann yazdı
      ...that had been added with f0215dcc "unotools:
      assert if TempFile::GetURL() fails due to missing file UCP".  But when SRCDIR is
      a read-only tree, JunitTest_sc_unoapi_2 fails with that assert firing when
      TempFile::GetURL is called from SfxMedium::CreateTempFile
      (sfx2/source/doc/docfile.cxx), which in turn is prepared to handle an empty
      return value from GetURL, and the test succeeds after removing the assert.  So
      it looks like that assert was not precise enough to only fire in the scenarios
      where it was intended to fire.
      
      Change-Id: I333e9026ee14e9d1140b1b475793a5b15ededd70
      Reviewed-on: https://gerrit.libreoffice.org/52085Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      d7a8fa7a
  25. 26 Mar, 2018 1 kayıt (commit)
  26. 19 Mar, 2018 1 kayıt (commit)
  27. 14 Mar, 2018 1 kayıt (commit)
  28. 08 Mar, 2018 1 kayıt (commit)
  29. 06 Mar, 2018 1 kayıt (commit)
  30. 02 Mar, 2018 3 kayıt (commit)
  31. 01 Mar, 2018 1 kayıt (commit)
  32. 24 Ock, 2018 1 kayıt (commit)
  33. 22 Ock, 2018 1 kayıt (commit)
  34. 15 Ock, 2018 1 kayıt (commit)
  35. 12 Ock, 2018 1 kayıt (commit)