Regression: trying to run the multipart to singleparts algorithm throws a python error

[nirvn]

What is the bug or the crash?

Trying to execute the multipart to singleparts algorithm fails on QGIS master. This regression has to have occured in this dev. cycle.

Steps to reproduce the issue

1. Launch QGIS
2. Open the processing toolbox panel
3. Try to launch multipart to singleparts algorihtm
4. Notice the python error

Stacktrace:

An error has occurred while executing Python code: 

RuntimeError: no access to protected functions or signals for objects not created from Python 
Traceback (most recent call last):
  File "/home/webmaster/apps/share/qgis/python/plugins/processing/gui/ProcessingToolbox.py", line 253, in executeAlgorithm
    in_place_input_parameter_name = alg.inputParameterName()
RuntimeError: no access to protected functions or signals for objects not created from Python


Python version: 3.9.7 (default, Sep  4 2021, 18:19:10) [GCC 10.3.0] 
QGIS version: 3.21.0-Master Master, b90e1be0cb 

Versions

QGIS master

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[nirvn]

@manisandro , could this be a fallout from your recent SIP changes? It had to regress within the last month or so, I've used these algorithms not long ago.

[manisandro]

With which sip version are you building?

[nirvn]

sip5-tools, hirsute (21.04) (devel), 5.5.0+dfsg-3

[manisandro]

Though the error message is actually accurate, QgsProcessingAlgorithm::inputParameterName is indeed protected.

[uclaros]

It works fine on 77be95f with sip 4.19.25+dfsg-1

[manisandro]

As I see it, the method should either be made public, or the C++ class wrapped in a Python class which exposes the C++ protected method

[manisandro]

PR #45331

[manisandro]

So replacing all occurences of protected: / protected slot: in the *.sip files fixes this. One can either do so in GENERATE_SIP_PYTHON_MODULE_CODE in SIPMacros.cmake, or one could do so directly in siplify.pl. I'd personally do it in the latter, at least it's clear already in the generated *.sip.in files that these methods are public and supposed to be so, not because of some dark magic happening later.
CC @nyalldawson

[nyalldawson]

That sounds good to me! @3nids do you agree?

[3nids]

yes, this sounds reasonable.
do we know this have changed?

see #45348

[manisandro]

I don't really know about the internals of sip / sip-build, and grepping protected through the sipbuild code didn't reveal much, so no not really - but I believe it's clearer like this anyway, rather then relying on internal sip logic.

[lbartoletti]

I don't really know about the internals of sip / sip-build, and grepping protected through the sipbuild code didn't reveal much, so no not really - but I believe it's clearer like this anyway, rather then relying on internal sip logic.

I don't know if it's related or can help, but sip-build have an option --protected-is-public:

SIP can generate code to provide access to protected C++ functions from Python. On non-Windows platforms this code can be avoided if the protected keyword is redefined as public during compilation. This can result in a significant reduction in the size of a generated Python module. This option enables the redefinition of protected and is the default on all platforms except Windows

[manisandro]

From my tests, this just adds -Dprotected=public to the command line when building the sip module from the generated sipModuleXXX.cpp files, so that code generated by sipbuild can access protected methods in the wrapped code. It does not prevent the build sip module enforcing the visibility of the methods of the wrapped classes at runtime.