What happens when you "alias" member variables with member function inputs/outputs?-CodePudding

What happens when a task input name is the same as a member variable name? Assume you have the following class:

virtual class foo;

  // This class is not intended to be instantiated nor extended.
  local function new; endfunction

  static bit [7:0] aByte;
  static bit [7:0] bByte;

  static task bar1();
    aByte = 8'h0A;
  endtask : bar1

  static task bar2(input logic [7:0] aByte);
    bByte = aByte   2;
  endtask : bar2

endclass : foo

program automatic main;
  initial
    begin
    foo::bar1();
    foo::bar2(8'h55);
    $finish;
    end
endprogram : main

I can't seem to find this situation in the IEEE standard. I don't want to make any assumptions of what is truly happening. Testing this in simulation yields bByte == 8'h57; this is what I expected. What is happening here? Is this an example of overloading? I'm mainly surprised that this even compiles, and more-so runs.

CodePudding user response：

Refer to IEEE Std 1800-2017, section 8.11 This.

The unqualified reference to aByte shall be resolved by looking at the innermost scope, in this case, the task argument declaration.

If you had a non-static task, to access the instance class property (aByte), it is qualified with the this keyword:

this.aByte

CodePudding user response：

This behavior is nothing specific to classes. What you are seeing is a local block namespace declaration that hides the visibility of a less local block declaration. See section 3.13 Name spaces in the IEEE 1800-2017 SystemVerilog LRM

The task bar2 creates a local scope with the argument aByte that hides the static variable declared within foo. you would have to use foo::aBtye to see the static variable. Search rules get completed depending on what kind of scope you are in. But see section 23.6 Hierarchical names to get started.