Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breathe fails to parse std::function typedef #291

Closed
Luthaf opened this issue Dec 6, 2016 · 6 comments
Closed

Breathe fails to parse std::function typedef #291

Luthaf opened this issue Dec 6, 2016 · 6 comments
Assignees
Labels
bug Problem in existing code code Source code upstream Issue in external software

Comments

@Luthaf
Copy link

Luthaf commented Dec 6, 2016

If I have code containing a std::function typedef containing a template return parameter:

typedef std::function<std::unique_ptr<Format>(void)> function_type;

Then I get an error from breathe:

WARNING: Invalid definition: Expected end of definition. [error at 37]
  std::function<std::unique_ptr<Format>void)> chemfiles::function_type
  -------------------------------------^

The error goes away if I use a non-template return type (int, ...). It looks like the opening parentheses is being eaten somewhere.

@vermeeren vermeeren self-assigned this Jun 2, 2018
@vermeeren
Copy link
Collaborator

vermeeren commented Jun 2, 2018

Could you check if this problem still exists with latest Sphinx (1.7.5) + Breathe (4.9.0)? Support for C++ has been vastly improved since the issue was opened.

@Luthaf
Copy link
Author

Luthaf commented Jun 4, 2018

With Sphinx 1.7.5 and Breathe 4.9.1, I get the following error:

Main error:
  Invalid definition: Expected end of definition. [error at 13]
    std::function<std::unique_ptr<Format>void)> chemfiles::function_type
    -------------^
Potential other error:
  Error in parsing template argument list.
  If type argument:
    Invalid definition: Expected ">" or "," in template argument list. [error at 37]
      std::function<std::unique_ptr<Format>void)> chemfiles::function_type
      -------------------------------------^
  If non-type argument:
    Invalid definition: Expected ">" or "," in template argument list. [error at 37]
      std::function<std::unique_ptr<Format>void)> chemfiles::function_type
      -------------------------------------^

The offending code is no longer part of my project, here is the reproduction code I used:

// test.hpp

#include <functional>
#include <memory>

namespace chemfiles {
class Format;
/// Test
typedef std::function<std::unique_ptr<Format>(void)> function_type;

}
.. test.rst

.. doxygentypedef:: chemfiles::function_type

@vermeeren vermeeren added bug Problem in existing code code Source code labels Jun 4, 2018
@jakobandersen
Copy link
Collaborator

With the code above from @Luthaf it looks like the missing opening parenthesis is already missing in the Doxygen XML.

@vermeeren vermeeren added the upstream Issue in external software label Jun 9, 2018
@vermeeren
Copy link
Collaborator

vermeeren commented Jun 9, 2018

I did a quick search through the Doxygen bug tracker.

https://bugzilla.gnome.org/query.cgi?format=advanced&product=doxygen

But could not find an issue for this.

Next steps will be opening a bug upstream, ref to it form here. Then probably implement a workaround specifically for std::functionin Breathe.

@t-b
Copy link
Contributor

t-b commented Jul 11, 2018

The doxygen output looks good AFAICJ:

<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<doxygen xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="compound.xsd" version="1.8.15">
  <compounddef id="test_8cpp" kind="file" language="C++">
    <compoundname>test.cpp</compoundname>
    <includes local="no">functional</includes>
    <includes local="no">memory</includes>
    <incdepgraph>
      <node id="1">
        <label>functional</label>
      </node>
      <node id="0">
        <label>test.cpp</label>
        <link refid="test_8cpp"/>
        <childnode refid="1" relation="include">
        </childnode>
        <childnode refid="2" relation="include">
        </childnode>
      </node>
      <node id="2">
        <label>memory</label>
      </node>
    </incdepgraph>
    <innernamespace refid="namespacechemfiles">chemfiles</innernamespace>
    <briefdescription>
    </briefdescription>
    <detaileddescription>
    </detaileddescription>
    <programlisting>
<codeline lineno="1"><highlight class="preprocessor">#include<sp/>&lt;functional&gt;</highlight><highlight class="normal"></highlight></codeline>
<codeline lineno="2"><highlight class="normal"></highlight><highlight class="preprocessor">#include<sp/>&lt;memory&gt;</highlight><highlight class="normal"></highlight></codeline>
<codeline lineno="3"><highlight class="normal"></highlight></codeline>
<codeline lineno="4"><highlight class="normal"></highlight><highlight class="keyword">namespace<sp/></highlight><highlight class="normal"><ref refid="namespacechemfiles" kindref="compound">chemfiles</ref><sp/>{</highlight></codeline>
<codeline lineno="5"><highlight class="normal"></highlight><highlight class="keyword">class<sp/></highlight><highlight class="normal">Format;</highlight></codeline>
<codeline lineno="7"><highlight class="keyword">typedef</highlight><highlight class="normal"><sp/>std::function&lt;std::unique_ptr&lt;Format&gt;(void)&gt;<sp/>function_type;</highlight></codeline>
<codeline lineno="8"><highlight class="normal"></highlight></codeline>
<codeline lineno="9"><highlight class="normal">}</highlight></codeline>
    </programlisting>
    <location file="test.cpp"/>
  </compounddef>
</doxygen>

and sphinx 1.7.5 also handles

.. cpp:type:: function_type = std::function<std::unique_ptr<Format>(void)>

properly.

@vermeeren
Copy link
Collaborator

It is likely this has been fixed somewhere at some point, likely in Doxygen. Assuming fixed for now, comment if not the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Problem in existing code code Source code upstream Issue in external software
Projects
None yet
Development

No branches or pull requests

4 participants