Skip to content

C
core
Dal (branch)/etiket değiştir
  1. 20 May, 2019 1 kayıt (commit)
  3. 04 Mar, 2019 1 kayıt (commit)
  5. 10 Şub, 2019 1 kayıt (commit)
  7. 29 Ock, 2019 1 kayıt (commit)
  9. 04 Kas, 2018 1 kayıt (commit)
  11. 09 Eki, 2018 1 kayıt (commit)
  13. 08 Eki, 2018 1 kayıt (commit)
  15. 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
  17. 31 May, 2018 4 kayıt (commit)
  19. 30 May, 2018 2 kayıt (commit)
    • Tor Lillqvist's avatar
      We might need to handle form controls as properties for OLE clients after all · 2b6a84c8
      Tor Lillqvist yazdı 
      Start a bit of work on that.

Change-Id: I7775f9598a81d64e9716996027b01f7f8e29745b
Reviewed-on: https://gerrit.libreoffice.org/55043Tested-by: 's avatarJenkins <ci@libreoffice.org>
Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
      2b6a84c8
    • Tor Lillqvist's avatar
      Hack to make properties work better from Automation clients · 7873bba6
      Tor Lillqvist yazdı 
      There were a couple of problems apparent at this stage when using the
ooovbaapi things from a test Automation client (written in VBScript,
to be precise).

Accessing for instance the ActiveDocument property of an
ooo::vba::word::XGlobals instance worked fine. But properties of other
objects, like instances of ooo::vba::word::XDocument, did not work.

When attempting to access any property of an
ooo::vba::word::XDocument, the code ended up calling the hasProperty()
of SwVbaDocuemnt. That function is for checking a totally different
kind of "properties", namely named form controls. Why form controls
are con-fused with oovbaapi properties I don't know. Maybe it is
intentional and as expected when using the oovbaapi from the built-in
Basic interpreter in LibreOffice. Or then just an accident in history.
Still, surely it can't be changed, that would break Basic scripts
embedded in existing ODF documents.

Anyway, from an OLE Automation client, for instance when asking for
the Content property of an ooo::vba::word::XDocument object, we
definitely don't want any form control that happens to have the name
"Content". We want an object with two integer properties, Start and
End.

Make this work by always creating an invocation factory instead of
using the object itself. Pass the invocation factory's
createInstanceWithArguments() function an extra argument indicating
this is the case of use from OLE Automation.

In the Invocation_Impl class in the stoc module, when this extra
argument is noticed, set a new mbFromOLE flag. Modify the behaviour
slightly when that is true. I am not at all sure that this will work
in all cases, but let's see, at least for simple tests so far it had
the intended effect.

Another issue was that looking up these properties was case sensitive.
This is wrong at least from languages like VBScript. Use the mbFromOLE
flag also to affect the case sensitivity behaviour.

Maybe I should simply make sure that _xDirect is null in the
Automation case? _Direct (a reference to an XInvocation) being
non-null probably means that we are using the document interface's own
implementation of XInvocation, which is probably always wrong in the
OLE Automation case. (Just see the SwVbaDocument implementations of
hasProperty() and invoke(), for instance.)

Change-Id: I2fd174f69f430893aef538cc9bf2a99d1c86b567
Reviewed-on: https://gerrit.libreoffice.org/55023Tested-by: 's avatarJenkins <ci@libreoffice.org>
Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
      7873bba6
  21. 25 May, 2018 1 kayıt (commit)
  23. 09 Şub, 2018 1 kayıt (commit)
  25. 05 Şub, 2018 1 kayıt (commit)
  27. 12 Ock, 2018 1 kayıt (commit)
  29. 11 Ara, 2017 1 kayıt (commit)
  31. 04 Eyl, 2017 1 kayıt (commit)
  33. 20 May, 2017 1 kayıt (commit)
  35. 19 Mar, 2017 1 kayıt (commit)
  37. 06 Şub, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Add missing #includes · 6dce9c67
      Stephan Bergmann yazdı 
      ...and remove some unncessary using directives/declarations, in preparation of
removing now-unnecessary #includes from cppumaker-generated files, post
e57ca028 "Remove dynamic exception
specifications".

Change-Id: Iaf1f268871e2ee1d1c76cf90f03557527ebc9067
      6dce9c67
  39. 01 Şub, 2017 1 kayıt (commit)
  41. 28 Ock, 2017 1 kayıt (commit)
  43. 26 Ock, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Remove dynamic exception specifications · e57ca028
      Stephan Bergmann yazdı 
      ...(for now, from LIBO_INTERNAL_CODE only).  See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.

Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly).  The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually).  There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).

Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code.  Missing @throws
documentation has not been applied in such manual clean-up.

Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574Tested-by: 's avatarJenkins <ci@libreoffice.org>
Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      e57ca028
  45. 19 Ock, 2017 1 kayıt (commit)
  47. 02 Ara, 2016 1 kayıt (commit)
  49. 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
  51. 18 Tem, 2016 1 kayıt (commit)
  53. 21 Haz, 2016 1 kayıt (commit)
  55. 20 Nis, 2016 1 kayıt (commit)
  57. 14 Nis, 2016 1 kayıt (commit)
  59. 12 Şub, 2016 1 kayıt (commit)
  61. 09 Şub, 2016 1 kayıt (commit)
  63. 15 Kas, 2015 1 kayıt (commit)
  65. 10 Kas, 2015 1 kayıt (commit)
  67. 05 Kas, 2015 1 kayıt (commit)
  69. 30 Eki, 2015 1 kayıt (commit)
  71. 12 Eki, 2015 1 kayıt (commit)