We are about to change how PsiElement.copy() works: currently calling this
method copies the tree of the whole file. The reason for this is to have a
constistent tree, so that it would be possible to examine the parent
elements of the copy later. It seems though that most of the clients do not
need to look at parent elements,
and the overhead of copying the whole file is really huge and often
So what I want to do in 5.0.3 (not in 5.0.2) is to copy only the subtree of
the element. The context of the copy would be the old element's parent, so
resolving references would work as before with the correction that the
references won't resolve to references in the copied file unless the
referenced element is in the copy itself. However it becomes illegal to
examine the psi of the copy parents with e.g. getContainingClass(),
getContainingFile() or getParent(). The code that needs this has to
explicitly call copy() for respective parent.
The places where we had to make modifications in our code were really few.
The question to you is, if you could survive this change in openapi in a
(not next) minor release, or should it be delayed until later?