Skip to content
New issue

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

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

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants