SV-EC Committee Meeting Monday November 19 2007 11:00am - 1:00pm PST Special meeting on name resolution issues "Unofficial notes" taken by Neil Korpusik PROVIDED FOR REFERENCE AND INFORMATION ONLY. This was a non-voting meeting. Arturo Salz Francoise Martinolle Mehdi Mohtashemi Neil Korpusik Gordon Vreugdenhil Mark Hartoog ** Unofficial notes taken by Neil Korpusik ////////////////// November 19, 2007 ///////////////////////// 1. Discussion Gord - he is working on issues related to structs - no desperate binding (backtracking) when contain doted names - it will be difficult to word carefully - would require a complete rewrite of the hierarchical reference sections - in the context of name resolution sections (22.6, 22.7) will introduce a sub-section that will talk about dotted names that sometimes don't represent hierarchy. - Will address places where decisions are made to determine when referring to hierarchy and when not. 1857 - parameterized classes Mark - had an issue with the following sentence: "The return type of an out-of-block declaration shall be specified prior to the out-of-block indication for the method." Gord - we might be able to just remove that sentence Arturo - "correct type" --> internal type - In example, why is the following not allowed? int x = C::p; Gord - C:: is never used to refer to the default specialization (for a parameterized class) Gord - Doug added a description on what is meant by default specialization - mailbox adds a type name, which opened the door to this whole issue - 2 years ago we may have made a different choice about the mailbox. Too late now. 1809 - relationships between $unit and function references Mark - do these also apply to sequences? - some customers think that properties and sequences should resolve the same way that tasks and functions do. Gord - thinks that they should - not sure if will be able to add in sequences at this point Might try to just add a small number of statements about that instead of modifying all of the related text FM - was asking about the generate example - initial f(); refers to function f() in the same scope. Gord - the same binding would occur if there was a function f() defined within the module, where the import exists today module top; function f(); // replacing the import in orig example if (1) begin: b initial f(); // binds to the the f() below function void f(); $display() endfunction end endmodule Mark - it is unfortunate that f() will be imported into module top, even though it ends up not being used. Arturo - if we waited until elab, for resolving f() we would end up with other backward compatibility issues. Gord - we get this "eager import" rule just for tasks and functions Arturo - concerns exist about where to issue an error Gord - outer imports versus your scope - another way to view it. wouldn't want to change rules for inner scopes. - ident names that escape a scope - do an import as a group on them. if (1) begin : b initial f(); // is f() found in current scope? // if not, it escapes the current scope // do import only if not otherwise found - we could do that but it will take a fair amount of time. - function names not really the problem - we would need to do one of the following 1. split out tasks, functions, properties and sequences 2. change existing rules in the appropriate places - since can't have unparenthesized function calls without dots in the names, could try to come up with a new way to resolve - we are only discussing an edge case here... FM - doesn't like the idea that a symbol is imported even when not used. - is ok with functions and tasks using different rules. Gord - there are already some cases where we have something similar Arturo - we have a mess, and this case is a convolution of them all together Gord - a provisional import versus and actual import.. - could talk about "initial f()" as a provisional import - Knows how to do this change, but doesn't know how to write it up The value of the rewrite may not be worth the effort required. - it is easy today to argue that "initial f()" today causes the import from the package. - The new rules are going to be a bit more restrictive. Some cases that would otherwise be legal are now going to be illegal. We could try to relax them in the next version of the LRM. Mark - if the wildcard import were in the generate block, we would end up with an error. - in the nested case the ref will trigger an import in the outer scope and the reference will be to the package. Gord - In the current LRM, there is no argument to say that the import would not happen. - we may want to fix this, but it would be difficult to show that the import in this example doesn't occur. - "initial f();" will bind to b.f(). FM - we have no other examples of something being imported but not used. Arturo - talking about a deferred import is the only way to talk about it. Gord - imports today are done in an eager manner They can then cause an error. FM - would like tasks and functions to have separate rules. Gord - he would support such a change, but doesn't have time to do a complete rewrite. FM - wants to say tasks and functions are not resolved the same way as other names. Gord - hierarchical names never do an import. Mark - deferred importing would probably make things work the way that users expect. Gord - you have to collect names up and then process them. - the current proposal fits in easily with existing LRM text. We could relax these rules next time around. FM - the problem is with the text that describes what would cause an import. Gord - requires going back to reexamine decisions about imports that have already occurred. - there might be some edge cases that will surprise users. not sure how severe it would be. Doesn't want to re-examine decisions about imports. FM - don't need to wait for elaboration time - just wait for the end of the scope Gord - $unit:: exists for disambiguation purposes Arturo - we need to decide on the rules first, then propose language FM - would like to make the rules the same as before Gord - packages change things in some cases. - there is no 1364 backward compatibility issue with this change - new errors can occur, and old errors can go away (with imports) module top; import p::*; // adding this now causes an error int f; if (1) begin : b initial f(); function void f(); Mark - this is just fallout from the Verilog rules. - he was thinking about deferring to elab time, but others don't like FM - never expected this type of fallout - doesn't like the idea of unneeded symbols being imported Mark - hasn't been able to come up with a way to do that. Gord - due to the concerns - there needs to be some time to address it. AI/FM - come up with a new proposal for 1809 that addresses her concern about importing symbols that then don't get used (ecd 12/10). 2214 - parameterized classes 2109 - Gord added it to this one Gord - believes that this is the correct behavior - the current writeup might be a bit more generous - should imported names be hierarchical referential? FM - no they shouldn't be Mark, Arturo - are in agreement Gord - the proposal - doesn't include those imported into the target scope. a bind uses x module int x; module import p::x; // this is now also visible // no hierarchical reference allowed to it. - local hierarchical references - not differentiated in the LRM - thinks it would be closer to what we discussed is to say only those names that are hierarchically referential. The proposal also includes those symbols that are imported. - Gord would be ok to forbidding imported declarations from participating in the bind. Neil - prefers the current wording Gord - the current wording allows for subtle differences in the way imports are handled (actually imported and potentially imported) - triggering an input would definitely be bad. FM - the LRM doesn't distinguish between the two. 2214 - put up for a vote on Nov 26 2211 - forward typedefs for types within classes Gord - what can you do with a forward typedef to a parameterized class? - Gord and Mark owe email on that point. - typedef intf.t interface typedef -- any suggested alternate wording for this? an interface type typedef Arturo - "It shall be an error if the prefix does not resolve to a class type or if the selected type name does not resolve to a type." - this may need to be reworded (partially redundant?). AI/Gord - update the proposal with this change. 2164 - "base class" instead of "parent class" in 8.12 Arturo - rewording AI/Mehdi - send email on this set - people should send input before the meeting 2215 2214 1857 - with a friendly amendment that was discussed 2211 - updated the proposal during the meeting 1702 - send input before the meeting on it as well. 2. Next meetings for sv-ec: -------------- Monday November 26, 2007 - Monday after Thanksgiving Monday December 10, 2007 =============== END OF UNOFFICIAL NAME RESOLUTION MEETING NOTES =============