fix Issue 21976 - importC: does not distinguish between cast-expression and unary-expression correctly

[WalterBright]

CParser was confusing a cast expression with a parenthesized expression.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21976	major	importC: does not distinguish between cast-expression and unary-expression correctly

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#12627"

[ibuclaw]

https://issues.dlang.org/show_bug.cgi?id=21976

[WalterBright]

This unnecessary ambiguity is one reason why D uses the cast keyword.

[ibuclaw]

This unnecessary ambiguity is one reason why D uses the cast keyword.

The ambiguity is precisely the reason why a symbol table would be better. The simplicity of C can be used to our advantage here, if an identifier hasn't previously been declared as a typedef typename, then it's not a cast.

[WalterBright]

There is another way. In the semantic code, if (T)*a is seen as a CastExp, the semantic analyzer can look at the T, see it's a variable, and rewrite it as a MulExp.

There's a similar issue with T * b; is it a Declaration or a meaningless Expression? A similar solution can be used.

These might be better than building an extra symbol table just for these two cases.

Anyhow, it's not a problem we need to deal with right now.

[WalterBright]

It's a bit harder problem than just keeping track of which identifiers are typedefs. Local scopes can re-declare identifiers as not-typedefs, so that would have to be accounted for.

[ibuclaw]

It's a bit harder problem than just keeping track of which identifiers are typedefs. Local scopes can re-declare identifiers as not-typedefs, so that would have to be accounted for.

Sure, I am accounting for that, and it still all works just fine in my head. :-)

typedef int i;       // check scope -> OK, no symbols yet: push to scope symbols
int i = 0;           // check scope -> Error redeclaration in same scope.
{   // push scope
    int i = 0;       // check scope -> OK, current scope has no symbols yet: push to scope symbols
    int a = (i) 42;  // 'i' found in current scope as symbol -> primary expression: error unexpected '42'
}   // pop scope
{   // push scope
    int a = (i) 42;  // 'i' found in outer scope as type -> cast expression
}   // pop scope

I'm sure you can think of more contrived examples, but what I'm imagining is a map using Identifier as the key, and a Type or Dsymbol as the result of the lookup.

[ibuclaw]

BTW, your commit message is referencing the wrong issue.

Other than that. I'm fine with pulling this as-is for now. But I'll be looking to improve the situation later, as there's bound to still be a failing test as a result of this.

fixed commit message

[WalterBright]

I know how to do the symbol table :-) but I think it may be easier to fix it in the semantic() code.