Declaring a constant with simultaneous initialization may result in an error depending on the lifetime and context

[chykon]

Hello!

Declaring a constant with simultaneous initialization may result in an error depending on the lifetime and context (for example, the location of the variable within a procedural block or function).

The expected behavior is that there will be no errors in all cases.

Example:

module tb;
  const static int a1;
  const static int a2 = 0;

  const automatic int b1;
  const automatic int b2 = 0;

  initial begin
    const static int c1;
    const static int c2 = 0; // error

    const automatic int d1;
    const automatic int d2 = 0; // error
  end

  function static void tb_func1();
    const static int e1;
    const static int e2 = 0;

    const automatic int f1;
    const automatic int f2 = 0; // error
  endfunction

  function automatic void tb_func2();
    const static int g1;
    const static int g2 = 0;

    const automatic int h1;
    const automatic int h2 = 0; // error
  endfunction
endmodule

Output:

%Error: tb/tb.sv:10:27: Assigning to const variable: 'c2'
                      : ... note: In instance 'tb'
   10 |     const static int c2 = 0;  
      |                           ^
%Error: tb/tb.sv:13:30: Assigning to const variable: 'd2'
                      : ... note: In instance 'tb'
   13 |     const automatic int d2 = 0;
      |                              ^
%Error: tb/tb.sv:21:30: Assigning to const variable: 'f2'
                      : ... note: In instance 'tb'
   21 |     const automatic int f2 = 0;  
      |                              ^
%Error: tb/tb.sv:29:30: Assigning to const variable: 'h2'
                      : ... note: In instance 'tb'
   29 |     const automatic int h2 = 0;  
      |                              ^
%Error: Exiting due to 4 error(s)

Command:

verilator tb/tb.sv --lint-only

---

Verilator version (git master): Verilator 5.023 devel rev v5.020-192-g292cc5476

OS (verilator devcontainer): Ubuntu 22.04.3 LTS

[wsnyder]

Perhaps you'd be willing to work on a pull request to fix this? Likely the warning just needs to be suppressed in these cases.