You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When documenting function signatures in C++ using the .. code-block:: directive in Sphinx-Needs, the attribute [[nodiscard]] (or similar double square bracket syntax) is incorrectly interpreted as a dynamic function by Sphinx-Needs. This results in a rendering error, where Sphinx attempts to process the content inside the [[...]] as a special directive or function, rather than rendering it as plain text within the code block.
Steps to Reproduce:
Use the following block in an RST file:
.. spec:: Program flow for subtraction method:status: open
.. code-block:: cpp \[[nodiscard]\] SomeStruct getInformation() const;
This method shall return the information vector of the class.
Build the documentation with Sphinx-Needs.
Expected Behavior:
The [[nodiscard]] attribute should be rendered exactly as it appears in the source code, without any modification or interpretation by Sphinx-Needs.
Actual Behavior:
Sphinx-Needs interprets [[nodiscard]] as a dynamic function, causing the documentation to either fail to render correctly or produce unintended results.
sphinx error:
Given dynamic function string is not a valid python call. Got: nodiscard
Workarounds Tried:
Escaping the square brackets using \[\[nodiscard\]\] or \[[nodiscard]\] results in the backslashes being rendered in the output, which is not the desired behavior.
Environment:
Sphinx Version: [7.1.0]
Sphinx-Needs Version: [3.0.0]
Python Version: [3.12.4]
Operating System: [macOS]
Additional Information:
This issue seems specific to Sphinx-Needs' handling of the [[...]] syntax in code blocks. It might be related to the processing of inline directives or dynamic functions within the documentation build process.
Suggested Fix:
A potential fix could involve updating the parser to ignore [[...]] within .. code-block:: or include an escaping mechanism.
The text was updated successfully, but these errors were encountered:
you could skip literal_block nodes and/or allow for escaping,
but honestly I feel it would be much better (and less surprising to users), to just remove this [[..]] parsing and let users instead use a role similar to https://sphinx-needs.readthedocs.io/en/latest/roles.html#need-func, for a singular dynamic function that can "detect" the need it is defined in, e.g. something like :need_df:`echo("first")`
Use-case:
When documenting function signatures in C++ using the
.. code-block::
directive in Sphinx-Needs, the attribute[[nodiscard]]
(or similar double square bracket syntax) is incorrectly interpreted as a dynamic function by Sphinx-Needs. This results in a rendering error, where Sphinx attempts to process the content inside the[[...]]
as a special directive or function, rather than rendering it as plain text within the code block.Steps to Reproduce:
Use the following block in an RST file:
Build the documentation with Sphinx-Needs.
Expected Behavior:
The
[[nodiscard]]
attribute should be rendered exactly as it appears in the source code, without any modification or interpretation by Sphinx-Needs.Actual Behavior:
Sphinx-Needs interprets
[[nodiscard]]
as a dynamic function, causing the documentation to either fail to render correctly or produce unintended results.Workarounds Tried:
\[\[nodiscard\]\]
or\[[nodiscard]\]
results in the backslashes being rendered in the output, which is not the desired behavior.Environment:
Additional Information:
This issue seems specific to Sphinx-Needs' handling of the
[[...]]
syntax in code blocks. It might be related to the processing of inline directives or dynamic functions within the documentation build process.Suggested Fix:
A potential fix could involve updating the parser to ignore
[[...]]
within.. code-block::
or include an escaping mechanism.The text was updated successfully, but these errors were encountered: