Please vote on IR 1070 VPI Issue 14 -- Prefixes in USE clauses

Please vote on this IR ASAP. We're trying to clear our plate for the 
upcoming
transfer of the Accellera VHDL LRM to the ieee.

Chuck Swart


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


VHDL Issue Number:      1070

Language Version:       VHDL-2002
Classification:         Language Definition Problem

Summary:                VPI Issue 14 -- Prefixes in USE clauses
Related Issues:         0190
Relevant LRM Sections:  TBD
Key Words and Phrases:  TBD

-----------------------
Author of Submission:   J. R. Armstrong (edited by Bill Paulsen)
Author's Affiliation:   Virginia Polytechnic Institute and State University
Author's Post Address:  Bradley Department of Electrical Engineering
                        Virginia Polytechnic Institute and State University
                        Blacksburg, VA 24061
Author's Phone Number:  (703) 231-4723
Author's Fax Number:    N/A
Author's Net Address:   JRA@VTVM1.CC.VT.EDU

Current Status:         Analyzed
Superseded By:          N/A
------------------------
Date Submitted:         1991/03/15
Date Analyzed:          6 March 2007
Author of Analysis:     Peter Ashenden
Revision Number:        2
Date Last Revised:      3 September 2007


Description of Problem
----------------------
(This IR supersedes IR 0190.)

  Can  the  same  prefix  be  used  in  multiple
  selected_names  in  a  USE  clause?  For  example,  is  "use
  work.definework.all, work.definework;" allowed?

  Test File: CH10/S04/01010104.vhd

  Comments:       (from      MCC)      The      line      "use
  work.definework.all,work.definework;" is in error since  the
  first  part  of  the clause "use work.definework.all" causes
  the name WORK to become not directly visible. Thus, the sec-
  ond part of this clause  "use  work.definework"  is  invalid
  since  the  name  WORK is now not directly visible. MCC sug-
  gests  changing  the  line  to  read  "use  work.definework,
  definework.all;"


  -- ##A4001114281FFA400121A400231**********************************************
  --+ File: [SUITE.CH10.S04]01010104.VHD
  --
  --+ Copyright (c) 1987, 1988 by CAD Language Systems, Inc.  All rights reserve
  --
  --+ LRM_version: IEEE Std. 1076-1987
  --
  --+ Subsets:
  --
  --+ Description:
  --
  --+ Test_point - (100400_010101) "A use clause achieves direct visibility of
  --  declarations that are visible by selection."
  --
  --+ Test_objective -(4) Test that when a declaration existing outside the scope
  --  of the immediate design region is needed, that a use clause can make that
  --  declaration visible. In addition, the library section of the LRM (section
  --  11.2) states that the use clauses:
  --             library STD, WORK; use STD.STANDARD.all
  --  should be implicit.  This test should succeed.
  --
  --+ References: Secondary LRM Coverage: (100400_010201)
  --                                      (100400_020301)
  --
  --+ Instructions: None
  --
  --+ Keywords: use clause, declaration, library, visibility
  --
  --+ Test_Results: Expect_success. Output_Checked.
  --
  --+ Test_Type: Locally Static Semantic
  --
  --+ History: Created MAT/CLSI 08-30-88
  --           Corrected KSC/VT 12-22-89
  --           Corrected CHC/VT 5-4-90
  --
  --+ Comments: CLSI-FILE: [000000.SCOPE.USECLAUSE]08
  --            MCC claimed that the order of selected names in the
  --            use clause is significant.
  --            This will be sent to VASG for clarification.
  --
  -- ***************************************************************************
  package definework is
   type work is array(0 to 31) of BIT;
  end definework;


  use work.definework.all,work.definework;
  entity E is
      port (P : in  bit);
  end E;

  architecture D3 of E is
      use  work.definework;
  begin
      process (P)
  -- This succeeds because type work is defined in package definework,
  -- there is no conflict with library "work"
       variable doit : definework.work ;  -- No_failure_here
      begin
      end process;
  end D3;


Proposed Resolution
-------------------
TBD


VASG-ISAC Analysis & Rationale
------------------------------

In the submitter's example, the use clause in the context clause
of entity E makes the name WORK defined in the package definework
potentially visible. The submitter asks whether that name hides the
library name WORK mentioned in the prefix of the second selected name
in the use clause.

Subclause 10.4 defines the scope of a use clause, and specifies that
it starts immediately after the use clause. Potentially visible
declarations are only considered in the scope of the use clause. Thus,
in the submitter's example, the declaration WORK.DEFINEWORK.WORK is
not potentially visible at the place of the second selected name in
the use clause, since that place is not after the use clause. The
comment from MCC is incorrect.

While this answers the submitter's direct question, there are some
further issues exposed by the question. In particular, had the use
clause been written as two separate use clauses:

  use work.definework.all;
  use work.definework;

the second use clause would be in the scope of the first use
clause. Whether the second use clause is then legal depends on whether
the potentially visible name WORK.definework.work is made directly
visible. That, in turn, depends on how the visibility rules apply to
library logical names. If they do, and the library name WORK
introduced by the implicit library clause is a homograph of the
potentially visible name, then the potentially visible name is not
made directly visible, and the second use clause is legal.

It is apparently the intent that the visibility rules apply to library
logical names. For example, 11.2 states:

  Within this scope each logical name defined by the library clause
  is directly visible, except where hidden in an inner declarative
  region by a homograph of the logical name according to the rules
  of 10.3.

However, the rules of 10.3 define the visibility of *declarations*. It
is not stated that a library logical name is a declaration. That can
be remedied by changing the above-quoted text to:

  For the purposes of the scope rules of 10.2 and the visibility rules
  of 10.3, the library clause is considered to be the declaration of
  the logical names it defines. Within the scope of a library clause
  each logical name ...

This change makes it clear that the normal scope and visibility rules
apply to library logical names.

With that clarification, in the submitter's example, the use clause is
legal and makes the names WORK.definework.work and WORK.definework
both potentially visible. The former is a homograph of the library
name WORK and is used in the immediate scope of the library clause
defining WORK, so it is not make directly visible. The latter is made
directly visible.


VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

Interpret 11.2 as specifying that library logical names be declared by
the defining library clause, and that the defining library clause be
considered a declaration for the purposes of 10.2 and 10.3.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Replace the last sentence of the first paragraph on page 158 with the
following:

  For the purposes of the scope rules of 10.2 and the visibility rules
  of 10.3, the library clause is considered to be the declaration of
  the logical names it defines. Within the scope of a library clause
  each logical name defined by the library clause is directly visible,
  except where hidden in an inner declarative region by a homograph of
  the logical name according to the rules of 10.3.