Rename conflicts

A rename is safe when every usage still refers to the same declaration afterwards, and nothing else starts referring to it. Before changing any file, the plugin simulates the new name using the same lookup rules as name resolution.

If it finds problems, the IDE shows a Conflicts Detected dialog listing them (usually only the first problem of each kind is listed; fixing it may reveal another). Choose Cancel, or Refactor Anyway if you are sure (for example when you are about to fix the other declaration too).

Conflicts that are reported

Conflict	Example	Message
Name already declared in the same scope (module, class, block, struct, package, or the project for modules, classes, packages)	rename a to b in a module that declares both; a struct field to another field’s name; module a to b when b.sv declares module b	'b' is already declared in this scope, 'b' is already declared in this struct, 'b' is already declared in b.sv
A usage would refer to something else: an inner declaration with the new name hides the renamed one	rename module signal a to b while block blk declares b and uses a	Usage of 'a' in 'a = 1;' would refer to another declaration of 'b'
An existing name would be captured: code that uses the new name today would start referring to the renamed declaration	rename a declared in block blk to b while the block uses module signal b	'b' in 'b = 1;' refers to another declaration and would be captured by the renamed 'a'
Import clash: a package item renamed to a name that an explicit import pkg::item; would bring into a scope that already declares it	rename p::y to x in a module with import p::y; and logic x;	'import p::y;' would import 'x' which clashes with the local declaration of 'x'
New override: renaming a method to the name of a virtual method of a base class, or so that a subclass method starts overriding it	rename d::g to f where base class base has virtual function void f()	Renaming to 'f' would override the virtual method 'f' of class base
Wildcard connection: a port or signal connected implicitly by .* would be disconnected or connected differently	rename port clk of sub instantiated as sub u(.*);	Port 'clk' is connected implicitly with .* in 'sub u(.*);'; renaming it would disconnect the port
Library code: the rename would have to change a file attached as a library	rename build_phase in a class whose base class is in a library file base.sv	'build_phase' overrides a library method in base.sv which cannot be renamed
Duplicate definitions: the same name is also declared in another file and both will be renamed	rename module m defined in a.sv and b.sv	'm' is also declared in b.sv; usages refer to both, so both declarations will be renamed

The check follows SystemVerilog’s name spaces: a module and a signal, or a package and a variable, may share a name, so renaming a signal to the name of a module is not a conflict.

Try it

1. In the sample project, open rtl/counter.sv and put the caret on state in state_t state;.
2. Press ⇧F6 (Shift+F6), type count in the Rename dialog and click Refactor. count is already the name of an output port of the module.
3. A dialog reports 'count' is already declared in this scope. Choose Cancel: nothing is changed.