Re: [sv-bc] Issue 131 / Mantis 2611 -- package/class lookup

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Fri Apr 24 2009 - 13:16:19 PDT
Gordon Vreugdenhil wrote regarding Mantis 2611:
If you claim that you must pay attention to the *type* of
C then you have issues with:
    package C;
      int y;
    endpackage
    module top #(type T);
      T C;
      int x = C::y;
    endmodule

Given that this is purely lexical search, I think it makes the
most sense to say that '::' prefix resolution is eager and
does package resolution only if no other intervening name
exists.
This part of your answer is a straw man argument.
There are no bindings of T which would ever make C::y a legal reference into the local object C.
My personal opinion is that this clearly refers to the package content, and that this is decidable
"lexcially" (i.e. by the parser) without reliance on any elaboration or runtime bindings.

Section 8.22 says (my emphasis added):
The left operand of the scope resolution operator :: shall be a class type name, package name (see 26.2),
covergroup type name, coverpoint name, cross name (see 19.5, 19.6), typedef name or type parame-
ter. When a typedef name or type parameter is used, the name shall resolve to a class or covergroup type
after elaboration.

The language grammar already requires us to distinguish between object and type identifiers when parsing;
doing so on behalf of a scope operator is not a big stretch.  Consider a reader's search for identifiers like C.
Knowing that it refers to a scope, hasn't he the right to limit his search to declarations of scopes?
Will you make him examine long port lists, and hunt for implicitly named wires to prove that the name hasn't
been shadowed?  Seems clear to me that he's got the package in mind.  You only put the declaration of C
nearby to make the puzzle seem compelling; it's no puzzle.  Folks use :: to refer to scopes, not objects.

Greg Jaxon


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Fri Apr 24 13:17:03 2009

This archive was generated by hypermail 2.1.8 : Fri Apr 24 2009 - 13:17:43 PDT