-
Declare copy operations of the affected classes noexcept to improve performance of classes that contain them. The implementations of the removed move constructors were wrong in case either the source or the destination (but not both) were disk-reference-counted. The move assignment operators were apparently correct but, as stated in added @note comments and detailed in this commit message below, they weren't useful in practice. Note that the removed IndexedInstantiationInformation's move operations contained another mistake: they used standardInstantiationInformationIndex() in place of 0 (see the implementation of IndexedInstantiationInformation(uint index)). I have analyzed the calls of copy and move constructors, assignment operators and swap() specializations for the three classes (IndexedIdentifier, IndexedQualifiedIdentifier, IndexedInstantiationInformation) by running statistics-printing-patched KDevelop several times with kdevelop, kate, ktexteditor and syntax-highlighting projects loaded. The results: 1. In the move assignment operators almost always either the indices are equal or neither operand is DUChain-reference-counted. Only in less than 0.5% of calls to IndexedQualifiedIdentifier's move assignment operator the indices differ and the left operand is reference-counted. The right operand is never reference-counted when the indices differ. 2. In the move constructors neither operand is ever reference-counted. 3. No swap() specialization is ever called. 4. Even in the copy special operations, never once both operands were reference-counted at the same time when the indices differed (the same is true for IndexedString, by the way). So in practice ItemRepositoryReferenceCounting's inc(), dec() and setIndex() implement the move operations optimally => remove the more complex moveIndex() helper function. a17d3f65 similarly removed IndexedString's move operations.
834fb13b
