[sv-ec] Some basic name resolution rules

Forwarding to the svec since this seems to be getting close to
becoming a proposal.

Neil



-------- Original Message --------
Subject: Some basic name resolution rules
Date: Mon, 14 May 2007 10:56:05 -0700
From: Gordon Vreugdenhil <gordonv@model.com>
To: Steven Sharp <sharp@cadence.com>, Francoise Martinolle <fm@cadence.com>, Shalom Bresticker <shalom.bresticker@intel.com>, Mark Hartoog <markh@synopsys.COM>, Gord Vreugdenhil <gordonv@model.com>,
"Dwivedi, Swapnil" <swapnil_dwivedi@mentor.com>, Paparao_Kavalipati@mentor.com, Neil.Korpusik@Sun.COM, Jonathan Bromley <jonathan.bromley@doulos.com>, Greg Jaxon <Greg.Jaxon@synopsys.COM>, Arturo Salz
<Arturo.Salz@synopsys.COM>, Melvin Cardozo <cardozo@cupertino.synopsys.com>

All,

I was recently in Chelmsford for a SV-CC meeting and took the
opportunity to have a direct chat with Steven and Francoise
regarding a general set of name resolution rules.  The
following is a summary of the basic rules that we think we're
agreed on.  I think that I'd like to try to get some variant
of this into Mantis as a proposal; I'm not sure that it is
going to be productive to attempt to write up an authoritative
reference algorithm but we should get some of the rules in
writing.  This is not meant to be an exhaustive set of rules
but I think that there are some meta concepts that should hold.

The two most critical concepts are that we want to minimize
the legacy impact of upwards backtracking resolution and we
want parsing to be a forwards only process -- there should
be no requirement to reconsider previous decisions.

Comments, feedback and suggestions are welcome.

Gord.


1. When a scope is finished its compilation, it is closed - no more
    symbol introduction.  The only exception is that an elaboration time
    "bind" can introduce additional instance names and implicit net names
    into the target scope.

    Implication -- external references, extern tasks, etc. cannot
    introduce new names.  The set of names in a scope is known when the
    "end" of the scope is encountered.


2. within a method, an identifier reference is resolved by doing searches
    in the following order:
       1. bind into the local scope (upwards to the method declaration)
       1. bind into the local class
       2. bind to any inherited names
       3. bind following normal lexical/import/hierarchy rules in
          the parent scope of the local class decl

3) for a package or class prefix, if a matching class name is visible,
    the class is the context, the package is last.

    Example:

        package C;
           int x;
        endpackage
        class C;
           static int x;
        endclass
        module top;
           int y = C::x;   // binds to visible class C not package C
        endmodule

4) package or class prefix names never back tracks in search
    (i.e. once you have matched a "<name>::" prefix, you will never
     back up and try again)

    Example:

        package C;
           int y;
        endpackage
        class C;
           static int x;
        endclass
        module top;
           int z= C::y;   // error -- "y" doesn't exist in class C
        endmodule



5) in a dotted name, if the first/next name binds to a declaration that
    MAY permit a dot select , no backtracking occurs.

    The "may" here is important.  The basic rationale of Steven and I is
    that we'd like to get rid of backtracking in the resolution other
    than in cases that are required for legacy support.

    The following is a legacy example:

       module top;
         integer x;
         child c();
       endmodule
       module child;
         integer top;
         initial top.x = 5;  // resolves to $root.top.x
       endmodule

     The following is a problematic case:

       module top;
         integer x;
         child c();
       endmodule

       module child #(type parameter T = int);
         T top;
         initial top.x = 5;
               // error at elab since "top.x" is required to
               // resolve into "T top"; is "T" is not a structure
               // type with an "x" this becomes an elab error
       endmodule


6) In a hierarchical name, once a "bit select" is matched to a scope
    that permits a bit select, no backtracking

    This means that once you've matched, for example, an arrayed generate
    name or an arrayed instance, you never backtrack upwards.

7) all class members are visible to the body of extern methods


     Example:

         class C;
           extern task foo;
           int x;
         endclass

         int x;
         extern task C::foo;
             x = 1;   // means this.x = 1
         end


     Implication:

         package p;
            int x;
         endpackage

         import p::*;

         class C;
           task foo;
               x = 1;   // means p::x
           end
           int x;
         endclass


8) An extern class method with a reference to an identifier that
    resolves outside the method (including other class members) shall
    resolve the identifier based on the point of declaration of the
    extern method.

    Example:

         package p;
            int x;
         endpackage

         import p::*;

         class C;
           extern task foo;
         endclass

         int x;
         extern task C::foo;
             x = 1;   // means $unit.x and not p::x
         end


     This is related to rule (1).  If one would want to treat the "x = 1"
     reference as p::x then you have to "go back" and determine that
     the "int x" declaration is an illegal conflict.  There should be
     no "going back" requirement.


-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-276-6385
Frontend Technologies (FTAP)                      Fax: 408-276-5092
Sun Microsystems                       email: neil.korpusik@sun.com
---------------------------------------------------------------------


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.