rename_symbol

Rename a symbol (variable, method, field, class, etc.) across the project.

Returns text edits for all occurrences that need to be changed. The caller should apply these edits to perform the rename.

USAGE: Position on symbol, provide new name OUTPUT: List of text edits to apply, and the files to rename

Each edit replaces exactly the symbol's simple name, also where a reference is qualified (an import, a static import, a qualified name in code or in a Javadoc link). An annotation element written as the single value of its annotation, @Tag("x"), is named before that value: @Tag(label = "x").

A type is renamed with its explicit constructors. A top-level type whose file is named after it renames that file: renamedFiles lists it, as {filePath, newFilePath}; apply the edits (editsByFile is keyed by the current paths), then rename the file. renamedFiles is present only when a file is renamed. A top-level type renamed to the name of a file that already exists in its folder is refused: INVALID_PARAMETER.

A method is renamed together with every method it overrides, every method that overrides it and every method a subtype inherits together with it, in and after lambda bodies included, and every call of them. A method of a class file, or a method renamed together with one, is refused, naming that method: it cannot be renamed.

A rename JDT's rename refactoring finds a conflict for is refused: INVALID_PARAMETER for newName, naming every conflict in JDT's words, by the place each names (a name another declaration in scope already has, a reference the renamed element would take over or lose, a unit with syntax errors, a native method, a static import of the new name). The conflicts of a type, a field, a local variable, a type parameter and a private, static or constructor method are those JDT's rename processors find; those of any other method are the conditions of JDT's method rename (RenameMethodProcessor, RenameVirtualMethodProcessor) checked on the Java model's own hierarchy, local and anonymous classes in lambda bodies included. JDT's warnings on a rename that goes ahead (such as a discouraged name, a constructor's name, or a method of the hierarchy with the new name and other parameter types) are listed in warnings, by place; warnings is present only when there is one.

A place JDT's search reports but cannot confirm as a reference, where a type or name does not resolve, is never edited: potentialMatches lists every one, to review by hand. A position on a name the compiler cannot resolve has no symbol to rename: SYMBOL_NOT_FOUND.

IMPORTANT: Uses ZERO-BASED coordinates.

potentialMatches, present only when there are any, holds the places JDT's search reports as possible matches but cannot confirm, because a type or name there does not resolve (a missing dependency or a compile error): count is their exact number, and locations lists them, as many as the results it stands beside may list. They are never counted or listed as results.

A module is renamed in its declaration and its references. A package (renamed with its folder, which no text edit does), a package declaration, an import declaration or the import list is refused: INVALID_PARAMETER for position, naming it. So is a type, field or method of a library (binary), which has no source to edit.

Requires load_project to be called first.