SV: parse.y method_qualifier missing few choices?

[svenka3]

I was looking for "pure virtual function" parse-only support (To get a structured code compiling).

Few sample SV lines that I am targeting:

  class drvr extends uvm_object;

    virtual function f();
    endfunction : f
    pure virtual function f1();
    endfunction 
    protected virtual function f2();
    endfunction 

  endclass

I see parse.y has:

method_qualifier /* IEEE1800-2005: A.1.8 */
  : K_virtual
  | class_item_qualifier
  ;

If I extend the above as shown below it seems to work - am I in the right direction?

method_qualifier /* IEEE1800-2005: A.1.8 */
  : K_virtual
  | K_pure K_virtual
  | class_item_qualifier
  ;

I do have a follow-up question, will ask once I get this one through.

Thanks

[caryr]

First, I think all this should trigger a "Sorry: not supported" message and error out by default, but I am okay if there is a flag to make this just print the message and omit the properties, etc. This probably should be added to all the "not supported" messages. I have a real problem just silently ignoring language constructs. Especially by default!

Yes, this looks correct. You may want to update the comment to refer to the correct section in the latest standard. Are you sure protected virtual is supported? I see how pure virtual protected is supported but not protected virtual.

[caryr]

Never mind the protected virtual comment. I missed something.

[svenka3]

Thanks Cary for the feedback. I agree on the danger of silent digestion of unsupported syntax. Will keep this in mind if I get to add any keywords in near future :-)

Now the other part of this seemingly simple "pure" keyword addition.

1. As per LRM, pure virtual methods require abstract class. I don't believe we are checking this. Not a big deal as abstract class is NYI as well.
2. For "pure virtual" function, there is no "endfunction" line as per LRM.

Given my limited experience with YACC/Bison, I am looking for how to handle this. Any references will help. If you believe it is too much to "teach", kindly ignore, will wait for one of you to implement this "tiny feature".

Thanks

[svenka3]

I believe I now have a code that works. Briefly it is below, will submit a PR for your review.

pure_virtual_method_decl /* IEEE1800-2012: A.1.9 */
  : K_pure K_virtual K_task IDENTIFIER ';'
  | K_pure K_virtual K_task IDENTIFIER '(' tf_port_list_opt ')' ';'
  | K_pure K_virtual K_function data_type_or_implicit_or_void IDENTIFIER ';'
  | K_pure K_virtual K_function data_type_or_implicit_or_void IDENTIFIER '(' tf_port_list_opt ')' ';'
  ;

[svenka3]

Taking clue from @caryr on silent parsing, I am considering the following message for pure virtual methods:

iv_uvm_pure_vir.sv:9: warning: OOP Pure Virtual methods are supported as parse-only No enforcement is done for a concrete class to define these further
iv_uvm_pure_vir.sv:10: warning: OOP Pure Virtual methods are supported as parse-only No enforcement is done for a concrete class to define these further
iv_uvm_pure_vir.sv:11: warning: OOP Pure Virtual methods are supported as parse-only No enforcement is done for a concrete class to define these further

Any inputs please?

[caryr]

Maybe:

...: sorry: "pure virtual" methods are currently not implemented. They can be allowed with no checks that "<method_name>" is implemented in a derived class by using "-w<some_flag>".

When "<some_flag>" is set (say "allow_parse_and_ignore" or maybe more specifically "allow_oop_parse_and_ignore") is given the message is not shown and it is not marked as a parse error. The flag name should be some thing that supports all the stuff you want to allow as parse only until we get it actually implemented.

[steveicarus]

I agree with Cary here. If you are going to add parsing support for this, it needs to "sorry" out.

[chykon]

Opened a related issue: #1061