"Creates a completely independent copy of N (a deep copy)."
Since we are creating new leaves, why prohibit their mutation sometimes?
I also don't quite understand the implications of having multiple leaves in a tree that are backed by the same token. I think the algorithm that produces edits can be confused by that.
If you agree, please change the implementation to use createLeaf (or call it directly from deepCopy).
Copy => DeepCopy? (also in other tests)
The canModify says whether the leaf is backed by a macro.
Since the tokens coming from macros are expanded they would be expanded in the deepCopy as well. We agreed that this shouldn't be the default behaviour. We can have deepCopyExpandingMacros, if the user wants this behaviour, but I think deepCopy should simply forbid macros.
WDYT about deepCopyExpandingMacros?
We think the current algorithm wouldn't be confused by that.
So we'll call createLeaf instead to create a fresh Leaf with the same Token as the previous one.
We are ignoring nullability of pointers.
The casting machinery asserts that on dyn_cast we don't have nullptr. So this code crashes on nullptr.
From what I understand dyn_cast et al. are intended to be used on pointers. Are there other alternatives to this approach? I would like to encode the non-nullability in types instead of in asserts....
That could be a useful operation that we can provide.
I don't think it is idiomatic in the LLVM/Clang style to use references for AST nodes and similar things. Beyond that, there is the issue that references are non-rebindable.
Does EXPECT_EQ work?