Allow additional extensions for c++ source files

[jonesinator]

A reasonably common practice for template classes is to place the class declaration in an h/hpp file, and then place the class definition in an ipp file and include the ipp file from the hpp file. For example, the boost libraries do this.

It seems as though the ipp files are not being considered c++ code by Coati. Consider the following files:

foo.hpp

#ifndef __FOO_HPP__
#define __FOO_HPP__

template <typename T>
struct foo
{
    void go();
};

#include "foo.ipp"

#endif /* __FOO_HPP__ */

foo.ipp

#include <iostream>
#include "foo.hpp"

template <typename T>
void foo<T>::go()
{
    std::cout << "Hello World!" << std::endl;
}

main.cpp

#include "foo.hpp"

int main()
{
    foo<int> my_foo;
    my_foo.go();
}

Makefile

all:
    clang++ -std=c++11 main.cpp

ipp-test.coatiproject

<?xml version="1.0" encoding="utf-8" ?>
<config>
    <language_settings>
        <language>C++</language>
        <standard>11</standard>
    </language_settings>
    <source>
        <header_search_paths>
            <header_search_path>/usr/lib64/../include/c++/5.3.0</header_search_path>
            <header_search_path>/usr/lib64/../include/c++/5.3.0/x86_64-unknown-linux-gnu</header_search_path>
            <header_search_path>/usr/lib64/../include/c++/5.3.0/backward</header_search_path>
            <header_search_path>/usr/local/include</header_search_path>
            <header_search_path>/usr/lib/clang/3.7.1/include</header_search_path>
            <header_search_path>/usr/include</header_search_path>
        </header_search_paths>
        <source_paths>
            <source_path>/home/aaronj/sandbox/ipp-test</source_path>
        </source_paths>
        <use_source_paths_for_header_search>0</use_source_paths_for_header_search>
    </source>
</config>

When Coati attempts analysis I get the following output 12:36:43 | Storage.cpp:1188 addSourceLocation() | ERROR: Can't create source location, file node does not exist for: /home/aaronj/sandbox/ipp-test/foo.ipp

Coati reports no errors were encountered:

However, the source of the go function can't be retrieved:

If I put the code in foo.ipp directly into foo.hpp and rerun the analysis things work as expected and the go function is no longer undefined.

It would be good to allow users to specify custom extensions that should be parsed by Coati as C/C++ code.

[mlangkabel]

Hi @jonesinator. Thanks for your really comprehensive report on that issue! Right now there are only a handful of file extensions that Coati detects by default.
In the current release of Coati you can extend that list by manually editing your .coatiproject file. To do so you need to add these extensions as subnodes of the source node in the following way:

<source>
   <extensions>
      <header_extensions><!-- STRING: extension for header/include e.g. .h --></header_extensions>
      <source_extensions><!-- STRING: extension for source e.g. .cpp --></source_extensions>
   </extensions>
   ...
</source>

For the case you mentioned above I would recommend adding the .ipp extension as a source_extension.
Editing the .coatiproject file by hand should be only a temporary solution while we are working on adding these settings to the project settings screen.

[jonesinator]

Thanks! I'm glad there's already a workaround in the product. I had to use header_extensions instead of source_extensions, but otherwise this worked for me. When I used source_extensions it complained about redefinition of foo<T>::go() I guess since the function was defined in foo.ipp and again by inclusion in main.cpp.

In case anyone has the same issue, the exact XML I used is below. It seems like specifying a single header_extensions entry overrides the default entries instead of adding to them, so I had to have a tag for both hpp and ipp even though hpp is normally automatically detected by Coati.

<source>
        <extensions>
            <header_extensions>.hpp</header_extensions>
            <header_extensions>.ipp</header_extensions>
        </extensions>
</source>

[mlangkabel]

@jonesinator: On a second thought adding the extension as a ´header_extension´ makes sense, as your compiler also wouldn't create a translation unit for that file.
Regarding the overridden header extensions: We implemented that policy so that one can get rid of the extensions we predefined (in case you don't want to analyze .h files ;) ). I think this will be much clearer once we added this setting to the GUI (I opened a new issue #49 for that).