artalus / odrey-clang Goto Github PK

Analyzing bigger compilation database can be potentially sped up by at least traversing separate files in parallel and then appending OdrMap with results.

Current implementation simply compares the text of definitions, instead of their semantic content and underlying types, which doesn't allow detecting cases like these:

using ViolatingAlias = float;
class SubtleViolationClass {
public:
	ViolatingAlias x;
	void fun() { std::cout << x << '\n'; }
};

//b.cpp
using ViolatingAlias = std::string;
class SubtleViolationClass {
public:
	ViolatingAlias x;
	void fun() { std::cout << x << '\n'; }
};

The possible way for comparing statements (function bodies) is present here.
Problem: stored Stmt* pointers invalidate somewhere after clang::ast_matchers::MatchFinder::MatchCallback's void run(const clang::ast_matchers::MatchFinder::MatchResult &result) exit.
Maybe matchers are a wrong approach and I need to switch to other ways of traversing AST.

Right now when started not from system path like /bin or /usr/bin, the tool argues that it cannot locate include files stddef.h, stdint.h etc. when parsing system headers like <iostream>. This of course causes mayhem and incorrect behavior.

The issue is related to clang builtin includes. To quote:

the default location to look for builtin headers is in a path $(dirname /path/to/tool)/../lib/clang/3.3/include relative to the tool binary. This works out-of-the-box for tools running from llvm’s toplevel binary directory after building clang-headers, or if the tool is running from the binary directory of a clang install next to the clang binary.

Another clue from pro.cxx

Berkus Decker, [15.03.18 11:09]
it is not /usr/bin, it is clang-install-dir wherever you've installed it, it is considered as root, since that's the way relocatable toolchain is done in LLVM

Another clue.

Once fixed, apply the same to leak-marker.

class RealisationDetail {
  int x;
  void set(int v) { x = v; }
};

///lib.h
class TotallyOk {};
///lib.a
class ImplementationDetail {
  const char buffer[256];
  void set(const char *str) { ... }
}

...Is this even collision, or would linker be smart enough to separate those? And if it is, are there any options besides emitting ODR-1338: file.cpp: defining symbol X, while lib.a also has symbol X exported?
It also would need some crossplatform readelf or nm to work.

• Search for <string> in /arm/target/usr/include instead of /usr/include
• Prevent clang builtin limits.h #include_nexting /usr/include/limits.h
• Ensure right primitives' sizeof when targeting different bitness (leading to sizeof(long) != SIZE_OF_LONG)

Clue from #llvm

@filcab [07.05.2018 1:15 PM]
You’ll want to explicitly add the target to your libclang command lines. You might want to add -isysroot too. If all else fails, do what I did for ycm and explicitly add the include paths that your compiler searches (check out the output of a compile with -v)

Can be partially worked around by providing -nostdinc++ -isystem /path/to/usr/include -isystem /path/to/cross-gcc/stdlib in compile_commads.json.

Probably those can be added with a commandline adjuster like the one in clang's CommonOptionsParser.cpp.

Another clue.

Once fixed, apply the same to leak-marker.

Check BugReporter.

Also diag().

• Split test project
• Automate runs similar to this