Initial support for xt::xtensor in LC

[czgdp1807]

#12

Test I am working on,

#include <iostream>
#include "xtensor/xtensor.hpp"
#include "xtensor/xio.hpp"
#include "xtensor/xview.hpp"

int main() {

    xt::xtensor<float, 2> arr1; /* { // TODO: Uncomment this initializer
      {1.0, 2.0, 3.0},
      {2.0, 5.0, 7.0},
      {2.0, 5.0, 7.0}}; */

    xt::xtensor<double, 1> arr2 {5.0, 6.0, 7.0};

    // xt::xarray<double> res = xt::view(arr1, 1) + arr2; // TODO: Uncomment this statement
    std::cout << arr2;

    return 0;
}

[czgdp1807]

Actually the scene with clang's ASTs is that the AST of a single header file isn't present under a single node. You have to visit a node like Decl (abstract node), check the file in which it is defined and if it's something inbuilt then LC ignores its processing. So if two FunctionDecl are present inside a header file then they will appear directly under the TranslationUnit. After visiting the first FunctionDecl you will not know whether the second FunctionDecl is also from the same header file. So you visit each AST node, check if its from a file which implements some inbuilt compiler feature (by pattern matching the path of the file), if so then you ignore that node and move on to the next. That's what I am doing right now. I think what we need to robust-ify here is to decide whether some header is to be ignored or not (just by using the path of the header which is the only thing available in Clang AST, other than that there is no information to figure out whether a particular AST node is from an inbuilt header or user defined header).

[certik]

We have to use the header path information that is available, and use some heuristics to determine which header this is (C++ standard library, XTensor, user header etc.) and then decide whether to ignore or include.

Once we have our own parser, and our own AST, we might decide to simplify this and use Clang AST plus our own heuristics to generate our own clean AST (that has nodes for header files) and then use AST->ASR for both paths (Clang and our own parser). However, our own AST might have some limitations (even if the full Clang AST is used to generate it), so let's postpone the decision here for later once we have more experience. For now let's do Clang AST directly to ASR and we just have to do our best.

[czgdp1807]

I will continue the work tomorrow and get it merged. We can improvise rest of the things later.

[czgdp1807]

We have to use the header path information that is available, and use some heuristics to determine which header this is (C++ standard library, XTensor, user header etc.) and then decide whether to ignore or include.

Correct. Clang AST doesn't have something like our ASR's module. Everything comes under TranslationUnit. Different functions from different header files come under the same TranslationUnit and everything appears as a user-written code.

[czgdp1807]

Merging.