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

Typedefs not used for standard types in some contexts #50

Closed
rhdunn opened this issue Jul 7, 2014 · 2 comments
Closed

Typedefs not used for standard types in some contexts #50

rhdunn opened this issue Jul 7, 2014 · 2 comments

Comments

@rhdunn
Copy link
Contributor

rhdunn commented Jul 7, 2014

Given:

std::list<std::string> foo();

The XML output expands the typedef in the return type:

<return>
  <type name="std::list&lt;std::basic_string&lt;char&gt;, std::allocator&lt;std::basic_string&lt;char&gt; &gt; &gt;" qualifier=" const &amp;" />
</return>

In other contexts, e.g.:

void foo(const std::string &)

the argument type preserves the typedef:

  <type name="std::string" qualifier=" const &amp;" />

Both contexts should use the typedef alias. That is, the return type should be:

<return>
  <type name="std::list&lt;std::string, std::allocator&lt;std::string&gt; &gt;" qualifier=" const &amp;" />
</return>
@rhdunn
Copy link
Contributor Author

rhdunn commented Jul 8, 2014

This also applies for:

struct foo { operator FILE *(); }

where cldoc produces:

<conversionfunction id="foo::operator struct _IO_FILE *" name="operator struct _IO_FILE *">
  <return>
    <type name="FILE" qualifier="*" />
  </return>
</conversionfunction>

@jessevdk
Copy link
Owner

jessevdk commented Apr 4, 2018

This should be fixed in latest master. This information appears to only be exposed correctly from libclang 4.0 and upwards, it seems this can't work correctly (information not being exposed) in 3.9. I'm considering only supporting 4.0+.

@jessevdk jessevdk closed this as completed Apr 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants