• Stephan Bergmann's avatar
    No need to keep these whitelisted functions decorated with SAL_CALL · 6f4f5677
    Stephan Bergmann yazdı
    The only effect SAL_CALL effectively has on LO-internal code is to change non-
    static member functions from __thiscall to __cdecl in MSVC (where all other
    functions are __cdecl by default, anyway).  (For 3rd-party code, it could be
    argued that SAL_CALL is useful on function declarations in the URE stable
    interface other than non-static member functions, too, in case 3rd-party code
    uses a compiler switch to change the default calling convention to something
    other than __cdecl.  But loplugin:salcall exempts the URE stable interface,
    anyway.)
    
    One could argue that SAL_CALL, even if today it effectively only affects non-
    static member functions in MSVC, could be extended in the future to affect more
    functions on more platforms.  However, the current code would already not
    support that.  For example, 3af50058
    "loplugin:salcall fix functions" changed FrameControl_createInstance in
    UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
    though its address (in ctl_component_getFacrory, in the same file) is passed to
    cppuhelper::createSingleFactory as an argument of type
    cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
    
    Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
    Reviewed-on: https://gerrit.libreoffice.org/46436Tested-by: 's avatarJenkins <ci@libreoffice.org>
    Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
    6f4f5677
fsfactory.cxx 7.14 KB