1. 16 Kas, 2018 1 kayıt (commit)
  2. 12 Kas, 2018 1 kayıt (commit)
  3. 04 Kas, 2018 1 kayıt (commit)
  4. 02 Kas, 2018 1 kayıt (commit)
  5. 01 Kas, 2018 1 kayıt (commit)
  6. 09 Eki, 2018 1 kayıt (commit)
  7. 24 Eyl, 2018 2 kayıt (commit)
  8. 18 Eyl, 2018 3 kayıt (commit)
  9. 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
  10. 15 Eyl, 2018 1 kayıt (commit)
    • Tor Lillqvist's avatar
      Re-think cppu::throwException() and the C++/UNO bridge on iOS · 7d6be61a
      Tor Lillqvist yazdı
      It seems that on iOS, where we don't have any Java, Python, BASIC, or
      other scripting, the only thing that would use the C++/UNO bridge
      functionality that invokes codeSnippet() was cppu::throwException().
      
      codeSnippet() is part of what corresponds to the code that uses
      run-time-generated machine code on other platforms. We can't generate
      code at run-time on iOS, that has been known forever. Instead we have
      used some manually written assembler to handle it instead. We used to
      have a Perl script to generate a set of code snippets for different
      cases, different numbers of parameters of the called function and
      whatnot, but that went away at some stage some year ago. (It is
      unclear whether that broke the C++/UNO bridge on iOS, or whether the
      stuff continued to work even after that.)
      
      Anyway, this handwritten assembly, or the manual construction of
      internal data structures for exceptions, or something else, seemed to
      have bit-rotten. Exceptions thrown with cppu::throwException() were
      not catchable properly any longer.
      
      Instead of digging in and trying to understand what is wrong, I chose
      another solution. It turns out that the number of types of exception
      objects thrown by cppu::throwException() is fairly small. During
      startup of the LibreOffice code, and loading of an .odt document, only
      one kind of exception is thrown this way... (The lovely
      css::ucb:InteractiveAugmentedIOException.)
      
      So we can simply have code that checks what the type of object being
      thrown is, and explicitgly throws such an object then with a normal
      C++ throw statement. Seems to work.
      
      Sadly the cppu::getCaughtException() API still needs some inline
      assembly in the C++/UNO brige. That seems to work though, knock on
      wood.
      
      This commit also adds a small "unit test" for iOS, copied from
      cppuhelperm to ImplSVMain(). Ideally we should not copy code around of
      course, but have a separate unit test app for iOS that would somehow
      include relevant unit tests from source files all over the place.
      Later.
      
      Change-Id: Ib6d9d5b6fb8cc684ec15c97a312ca2f720e87069
      Reviewed-on: https://gerrit.libreoffice.org/60506
      Tested-by: Jenkins
      Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
      7d6be61a
  11. 05 Eyl, 2018 1 kayıt (commit)
  12. 29 Agu, 2018 1 kayıt (commit)
  13. 16 Agu, 2018 2 kayıt (commit)
  14. 09 Agu, 2018 1 kayıt (commit)
    • Mike Kaganski's avatar
      Don't use internal __CxxDetectRethrow: it has side effects · 8313116f
      Mike Kaganski yazdı
      Since the __CxxDetectRethrow may increment __ProcessingThrow, which then
      must be decremented in __CxxUnregisterExceptionObject, and the latter does
      many other funny things with exception handling CRT machinery, we cannot
      use those internal functions (neither alone, nor together), or we end up
      breaking runtime's expectations: the runtime code checks __ProcessingThrow
      left and right, expecting its non-0 value to indicate "we are unwinding...
      possibly called from a dtor()". In this case, e.g., std::current_exception
      returns nullptr inside catch block.
      
      This creates our own copy of __CxxDetectRethrow, which does not mangle the
      global state, and just performs the same checks. This is a dirty hack, and
      it relies on current layout of the exception description layout - so must
      be synchronized in the event of changes!
      
      Change-Id: I2c475fbc2468073b796c7e9d0f4dfcd315896489
      Reviewed-on: https://gerrit.libreoffice.org/58730
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      8313116f
  15. 04 Agu, 2018 2 kayıt (commit)
  16. 03 Agu, 2018 1 kayıt (commit)
  17. 27 Tem, 2018 1 kayıt (commit)
  18. 23 Tem, 2018 1 kayıt (commit)
  19. 09 Tem, 2018 1 kayıt (commit)
    • Gabor Kelemen's avatar
      Add missing sal/log.hxx headers · 7af90cc9
      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 a* to configmgr
      
      Change-Id: I6ea1a7f992b1f835f5bac7a725e1135abee3f85a
      Reviewed-on: https://gerrit.libreoffice.org/57170
      Tested-by: Jenkins
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.co.uk>
      7af90cc9
  20. 15 May, 2018 1 kayıt (commit)
  21. 07 May, 2018 1 kayıt (commit)
  22. 16 Nis, 2018 1 kayıt (commit)
  23. 10 Nis, 2018 1 kayıt (commit)
  24. 20 Mar, 2018 1 kayıt (commit)
    • jan Iversen's avatar
      iOS, simplified assembler · 5747ed05
      jan Iversen yazdı
      RC of cpp_vtable_call is never used in the asm part, so remove it.
      
      Change-Id: Iabda12541fbb574a21395a8430c52a3e9f892947
      5747ed05
  25. 17 Mar, 2018 2 kayıt (commit)
  26. 16 Mar, 2018 2 kayıt (commit)
  27. 15 Mar, 2018 3 kayıt (commit)
  28. 11 Mar, 2018 4 kayıt (commit)
    • jan Iversen's avatar
      iOS, calling cpp_vtable_call does not corrupt stack · 814bd400
      jan Iversen yazdı
      Changing bl -> b (jump long to jump) allowed cpp_vtable_call
      to work without corrumping the stack.
      
      However return still corrumpts the stack.
      
      Change-Id: I3437a73139b65af13dcf6fa0c959bb1c847564b9
      814bd400
    • jan Iversen's avatar
      iOS, moved privateSnippetExecutor from asm to C function. · 056bc3cf
      jan Iversen yazdı
      move asm code to C as first step towards reducing the asm code.
      Since iOS does not permit java/python or anything else than the
      compiled C++ code, the throw should be done simpler.
      
      Apart from that this is the first step in solving a stack
      corruption problem in the throw code
      
      Change-Id: I4f3d3a3ba3f55fb46131d9a8eeb0deebf179d95f
      056bc3cf
    • jan Iversen's avatar
      iOS, removed unneeded #ifdef arm64 · 5facd232
      jan Iversen yazdı
      Change-Id: Ie568c461ae834b33b9220c4b9fb42ec66b5e7ce0
      5facd232
    • jan Iversen's avatar
      iOS, revert bed135e0 · 6ec77e28
      jan Iversen yazdı
      using USE_DOUBLE_MMAP worked well on the device, but caused
      problems with the simulator, that depends on the GCC3_MAC* implementation.
      
      Change-Id: Ifbc1d48b3642567029c5271054a545eaacaf18ed
      6ec77e28