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

Function parameters are not visited #20

Open
sztomi opened this issue May 14, 2017 · 5 comments
Open

Function parameters are not visited #20

sztomi opened this issue May 14, 2017 · 5 comments

Comments

@sztomi
Copy link
Contributor

sztomi commented May 14, 2017

I think this is because member_function_t is not treated as a container in detail::visit, and simply the callback is called instead of recursive visitation. I'd assume standardese would need to parse function paramters, wouldn't it?

  • cppast version: 2be20f6
  • parser: libclang_parser
  • clang version: 4.0

Explanation of the error.

Input:

    auto code = R"(
          class foo {
            void f(int a, int b){};
          };
    )";

    cpp_entity_index idx;
    auto file = parse(idx, "cpp_class.cpp", code);
    unsigned filtered_count = 0;
    auto visitor_callback = [&](const cpp_entity &e, cppast::visitor_info info) {
      if (info.event == cppast::visitor_info::container_entity_exit)
        return true;
      std::cout << e.name() << " : " << cppast::to_string(e.kind()) << "\n";
    };

    cppast::visit(*file, visitor_callback);

Output:

cpp_class.cpp : file
foo : class
f : member function

I would expect the function parameters a and b to be visible in the output.

@foonathan
Copy link
Collaborator

Are they visited if you visit a function? If not, that's by design, template parameters aren't visited as well, you'd have to iterate over . parameters () then.

Feel free to question that design decision though.

@sztomi
Copy link
Contributor Author

sztomi commented May 15, 2017

So do you mean I should cast the entity to cpp_member_function and it has a paramaters() member? That's workable for me. Not sure if I would criticize the design, though I'm not sure if this scales well for when function bodies will be parsed.

@foonathan
Copy link
Collaborator

Yes, cast​ and you'll have everything.

The general problem is: how do I handle entities that have more than one kind of children? The best example is a class, it has base classes and members, should both be visited?

@sztomi
Copy link
Contributor Author

sztomi commented May 15, 2017

It does feel natural to have everything in the tree, and allows uniform appending/deleting of source "items" when source rewriting is implemented. I wonder libclang or libtooling do in this case?

@foonathan
Copy link
Collaborator

It depends on the entity, they sometimes visit, sometimes don't. I'll see what I can come up with.

@foonathan foonathan self-assigned this May 25, 2017
@foonathan foonathan removed their assignment Mar 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants