Only output types and methods from the original header

[jonas]

In the native types test both the uchar.h and stddef.h header files are included which depending on the platform will generate additional type aliases and structs definitions for types read from those headers even if those types are unused.

[jonas]

Depends on the IR work done in #6

[kornilova203]

@jonas, should we remove unused types and structs that are declared only in included headers or all unused types and structs?

I wrote code that removes unused types in filter-unused-types branch but it is not aware from where these types came from

[jonas]

Depends on type representation in the IR: #52

[kornilova203]

How do we decide that type may be removed?
We already have filtering by prefix by prefix that should remove platform specific types.
We should not remove all unused typedefs simply because they may be used by other bindings.

[jonas]

This issue can be repurposed as an initial step towards #2. We need to track which header file declared a type and based on that we can prune (or ignore) any type not declared in the header file for which we are generating bindings.

Note that eventually we need to support generating bindings for multiple header files.

[jonas]

I've retitled the issue based on the above comment.

[jonas]

From looking into this, it should be possible to use clang::ASTContext.getSourceManager() to get the file name of any clang::Decl processed by TreeVisitor.

Methods not in the original header can be discarded right away, while types will have to be added to the IR in case we have to reference it, e.g. stdio.FILE, or resolve it, e.g. type a = __darwin_a; type __darwin_a = native.CInt => type a = native.CInt.

On macOS I noticed that some standard headers are merely wrappers, e.g. /usr/include/ctype.h leaves all declarations to /usr/include/_ctype.h. So a lightweight way to configure and support such a use case is necessary.

[jonas]

I'm also wondering if we should put in place a proper class to track the origin of a declaration. Main can then add the initial instance to the IR and load+add known instances from stdHeader.config.

The class should contain:

• Include path or basename (ideally paths and basenames)
• Scala package+object name