1. 05 Haz, 2019 1 kayıt (commit)
  2. 22 May, 2019 1 kayıt (commit)
  3. 12 May, 2019 1 kayıt (commit)
  4. 09 May, 2019 1 kayıt (commit)
  5. 20 Nis, 2019 1 kayıt (commit)
  6. 29 Mar, 2019 1 kayıt (commit)
  7. 25 Mar, 2019 1 kayıt (commit)
  8. 17 Mar, 2019 1 kayıt (commit)
  9. 05 Mar, 2019 1 kayıt (commit)
  10. 04 Mar, 2019 2 kayıt (commit)
  11. 03 Mar, 2019 1 kayıt (commit)
  12. 19 Şub, 2019 1 kayıt (commit)
  13. 14 Şub, 2019 1 kayıt (commit)
  14. 08 Şub, 2019 1 kayıt (commit)
  15. 28 Ara, 2018 1 kayıt (commit)
  16. 17 Ara, 2018 1 kayıt (commit)
  17. 08 Ara, 2018 1 kayıt (commit)
  18. 21 Kas, 2018 1 kayıt (commit)
  19. 11 Kas, 2018 1 kayıt (commit)
  20. 10 Kas, 2018 1 kayıt (commit)
  21. 04 Kas, 2018 1 kayıt (commit)
  22. 27 Eki, 2018 1 kayıt (commit)
  23. 24 Eki, 2018 1 kayıt (commit)
  24. 22 Eki, 2018 1 kayıt (commit)
  25. 17 Eki, 2018 2 kayıt (commit)
  26. 09 Eki, 2018 1 kayıt (commit)
  27. 01 Eki, 2018 1 kayıt (commit)
  28. 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
  29. 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
  30. 10 Eyl, 2018 1 kayıt (commit)
  31. 29 Agu, 2018 1 kayıt (commit)
  32. 28 Agu, 2018 1 kayıt (commit)
  33. 13 Agu, 2018 1 kayıt (commit)
  34. 09 Agu, 2018 3 kayıt (commit)
  35. 04 Agu, 2018 1 kayıt (commit)
  36. 29 Tem, 2018 1 kayıt (commit)