Expansion the semanics of NamedExpression

[HungMingWu]

Hi, Mike... I met another issue about reference issue.
Here is another case.

module test;
	enum { red, green, blue } color;
	bit [3:0] pixel_adr, pixel_offset, pixel_hue;

	covergroup g2;
		Hue : coverpoint pixel_hue;
		Offset : coverpoint pixel_offset;
		AxC : cross color, pixel_adr;
		all : cross color, Hue, Offset;
	endgroup

	initial begin
		static integer i = 0;
	end
endmodule

When I visit CoverCrossSymbol, I found three NamedValueExpression expressions,
color, pixel_hue, pixel_offset
But I need to find its related CoverpointSymbol, it is simple in this case.
But if I rewrite to

module test;
	enum { red, green, blue } color;
	bit [3:0] pixel_adr, pixel_offset, pixel_hue;

	covergroup g2;
		Hue : coverpoint pixel_hue;
		Offset : coverpoint pixel_hue;
		AxC : cross color, pixel_adr;
		all : cross color, Hue, Offset;
	endgroup

	initial begin
		static integer i = 0;
	end
endmodule

it fails due to two CoverpointSymbol owns the same VariableSymbol
But if relax the expression, let it be color, Hue, Offset, it seems more elegant.
The problem is only 'NamedValueExpressionexist. According last discussion, you suggest useHierarchicalReferenceExpression `.
The code would become

void visit(const HierarchicalReferenceExpression& expr) {
    if (auto crossPointSymbol = expr.symbol->as_if<CrossPointSymbol>()) {
    } else if (auto assertionPortSymbol = expr.symbol->as_if<AssertionPortSymbol>()) {
    } ...
}

It feels ugly.
I tried to use another method is extend it.

template <typename T>
class SLANG_EXPORT NamedExpression : public Expression {
public:
    const T& symbol;

protected:
    NamedExpression(ExpressionKind kind, const T& symbol, SourceRange sourceRange) :
        Expression(kind, symbol.getType(), sourceRange), symbol(symbol) {}
};

class SLANG_EXPORT ValueExpressionBase : public NamedExpression<ValueSymbol> {};
class SLANG_EXPORT NamedAssertionPortExpression : public NamedExpression<AssertionPortSymbol> {};

So my visitor becomes

void visit(const NamedAssertionPortExpression& expr) {}

Do you think it is a good idea?

[MikePopoloski]

I'm having a hard time following what you're asking. Why are there HierarchicalReferenceExpressions in your example with cover points? How does this relate to assertion declarations?

The suggestion to have a NamedAssertionPortExpression doesn't make sense to me because assertion ports are not referenced in expressions, they are instead expanded inline like a macro argument would be (the LRM requires it be done this way because it can subtly change the semantics of the resulting expression).

My suggestion in the previous discussion was to change just the assertion port case where we are fake-instantiating a sequence or property that is otherwise unused in the design -- in that case the ports, instead of being invalid expressions pointing to nothing, can instead be an invalid expression pointing to something that can hold the assertion port symbol. The HierarchicalReferenceExpression already exists so I figured that could be used. This would just be for convenience of people using the API, it would not otherwise affect any behavior.