No idea why the conversion fails for the wide string.
First step is to reproduce the problem. I guess we should try in a Ubuntu VM.
Is there an easy way to see if other builders succeeded?

I've suggested some more refactorings but otherwise this should be good to go

I wonder if clang-diff is useful in its current state, I remember there are many edge cases left over.

I'm having some troubles fixing this build failure:
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/1866/

check if the function's section is executable

• Use addr.IsSectionOffset() as suggested.
• Add test that links two copies of a compilation unit and makes sure that lldb only resolves it once.

Thanks for the very useful feedback! Now I can finally see why this is happening.

different approach (WIP): ignore functions with DW_AT_low_pc = 0

typo

update comment and commit message

duplicate of https://reviews.llvm.org/D70894

In D70302#1763025, @rnk wrote:

Fix looks good post commit, but we should enhance the test.

Committed as 1ac700cdef787383ad49a0e37d9894491ef19480 - this should be a safe fix

update commit message

Remove unnecessary const on parameter

In D34329#1213667, @sylvestre.ledru wrote:

@arphaman @johannes Is that normal that clang-diff isn't installed by cmake? (like clang-format?)

use generic concat

In D40782#960474, @hfinkel wrote:

In D40782#958027, @johannes wrote:

I use a different approach now, WDYT?

I'm not sure I like this. Before it was clear: !strconcat is for strings, !codeconcat was for code. Having !strconcat also work on code, and return something which isn't a string, seems unfortunate. And we also have !listconcat. If we want to unify things, I think it would make sense to add !concat (which works on all of those things). [If you do this, then also support !strconcat and !listconcat as aliases to be nice to out-of-tree backends].

I use a different approach now, WDYT?

remove codeconcat, make strconcat return code if all arguments are

add documentation + test

In D40731#943564, @stettberger wrote:

For my changes to StmtDataCollectors: I tried to leave the already existing entries in StmtDataCollector.td untouched and the test-cases still work OK. If there is something somebody could break by changing these files it would be good to have a test case for it.

So you can define a category for cHash and add let cHash = [{ .. }] or let cHash = TypeIIClone; if you just want to reuse it.
With this patch you can also use !codeconcat to append some code: https://reviews.llvm.org/D40782

adhere to the column limit

I think it would be quite nice if we manage to consolidate the implementation of hashing mechanisms.

update

update

update

use raw source code of owned tokens instead

update

update

use CXXOperatorCallExpr::isPrefixOp() to determine whether it's infix or postfix
directly traverse statement children instead of copying

@teemperor ok for you? did phabricator make you a blocking reviewer because of the affected code, or did I do that somehow?

undo visibility change

In D37383#858905, @teemperor wrote:

@arphaman I suggested tablegen in D36664 because I remembered we had some CMake sanity check about not having an *.inc in our include dir: https://github.com/llvm-mirror/clang/blob/master/CMakeLists.txt#L266 Not sure if it actually fires for our case, but it looks like it does.

fix by adding an option in RecursiveASTVisitor

fixes

This is currently broken, if a user provides a TraverseClassTemplateDecl, then the same method in this class will not be called, I think I will add a flag (probably not user visible) in RecursiveASTVisitor.h to switch the order for templates

Yeah, this seems to be the best solution for this. I think I ran into the same issue when working on the StmtDataCollector - basically there can only be two Traverse*, one in the Derived class and the other one needs to do all the magic with walking the specialisation hierarchy.

use a specialized getStmtChildren to fix the order for CXXOperatorCallExpr

split to ASTDiff/ASTPatch

detect prefix/postfix from number of arguments

The previous version didn't call TraverseDecl of the derived class, this is fixed now.
The public getDerived.TraverseStmt() does not accept a DataRecursionQueue, so this also could not be used (I think)
I used the wrapper TraverseStmtBase, which should behave exactly as the method that originally traverses CXXOperatorCallExpr

do call derived TraverseStmt for children of CXXOperatorCallExpr

use RecursiveASTVisitor::TraverseStmt