This is an archive of the discontinued LLVM Phabricator instance.

[clang][WIP][clang-scan-deps] Add an experimental C API.
Needs ReviewPublic

Authored by Bigcheese on Nov 15 2019, 5:42 PM.

Details

Reviewers
arphaman
kousikk
Summary

This adds an experimental C API for clang-scan-deps. It provides both
the full module dependency graph along with a flattened list of
dependencies.

See clang/include/clang-c/Dependencies.h for the API and documentation.

You can test it out using:
c-index-test core --scan-deps <working-directory> -- clang --cc1 <args>

This will output a list of modules and then the direct dependencies of
the main translation unit.

This is based on a patch by Alex Lorenz.

Diff Detail

Event Timeline

Bigcheese created this revision.Nov 15 2019, 5:42 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 15 2019, 5:42 PM
Bigcheese edited the summary of this revision. (Show Details)Nov 15 2019, 5:46 PM

Adding experimental APIs is something that we haven't done before, but it be useful for this case.
I have a couple of questions about the API:

  • Should types be prefixed / suffixed with experimental / v0 in case we need to extend the information passed to the client?
  • The types look to be more geared towards Clang modules (like the addition of a module map path). Do you think the same types could be used for C++ 20 modules as well, or should C++ 20 modules have a completely separate API?

Adding experimental APIs is something that we haven't done before, but it be useful for this case.

Yep, I'm currently aware of two other people who care about this interface, so I thought it would make sense to do the development of the API upstream.

I have a couple of questions about the API:

  • Should types be prefixed / suffixed with experimental / v0 in case we need to extend the information passed to the client?

I don't think the type names matter unless someone plans to write a user of this API that can handle multiple versions at the same time (which means they aren't using this header). The function names matter as that's what shows up in the symbol table.

  • The types look to be more geared towards Clang modules (like the addition of a module map path). Do you think the same types could be used for C++ 20 modules as well, or should C++ 20 modules have a completely separate API?

C++20 modules will need to use the same API as we intend to support mixing Clang modules and C++20 modules. The types will need to be modified slightly to work for C++20 modules, I just haven't gotten to that yet. C++20 module interfaces don't need a module-map or equivalent, and C++20 header units will just need to know the header file they are for.

arphaman added inline comments.Nov 21 2019, 5:53 PM
clang/include/clang-c/Dependencies.h
206

Looks like you have a duplicate declaration of this function, and the prototype above is missing the comment.

I think this patch is missing tests for the C api that use c-index-test.

kousikk added inline comments.Nov 21 2019, 6:42 PM
clang/include/clang-c/Dependencies.h
147

It would be simpler if the clients didn't have to worry about the worker?
As far as a user of this lib is concerned, they need to create a shared cache, then call scanDeps() in some form with the shared cache and other inputs.

Can we hide the worker inside the implementation? So essentially we create a new worker for every invocation (that's assuming worker setup is cheap).

Bigcheese marked an inline comment as done.Nov 22 2019, 1:12 PM
Bigcheese added inline comments.
clang/include/clang-c/Dependencies.h
147

A lot of caching is per-worker. It would be pretty bad to spawn a new worker for every scan.

Bigcheese updated this revision to Diff 232484.Dec 5 2019, 6:02 PM
Bigcheese marked an inline comment as done.
  • Remove duplicate decl
  • Add test

I was finally able to land the patch this depended on. Still waiting on review for this. In the meantime I've tested this ABI out by building a simple program that outputs a ninja file given a command line. It depends on a bunch of changes to the Clang side of things, but no changes to this interface.

@Bigcheese wondering if there are things with respect to testing we can do, to help the patch move forward :)

I mostly just need to rebase this patch now. I'll try to get to that soon.