Compiling my current project I get:

Assertion failure: 'f' on line 2695 in file 'expression.c'

I poked around in expression.c to see if I can get an idea of what to look for to fix this, but I'm clueless. The verbose option tells me this occurs in the semantic3 pass and (I assume) the file being scanned when the assertion occurs - but I've got nothing else to go on.

So my question is, what sort of things should I be looking for to get rid of this?

This should help: www.digitalmars.com/bugs.html

"Mike Parker" <aldacron71@yahoo.com> wrote in message news:ca791i$2n9c$1@digitaldaemon.com...
> Compiling my current project I get:
>
> Assertion failure: 'f' on line 2695 in file 'expression.c'
>
> I poked around in expression.c to see if I can get an idea of what to look for to fix this, but I'm clueless. The verbose option tells me this occurs in the semantic3 pass and (I assume) the file being scanned when the assertion occurs - but I've got nothing else to go on.
>
> So my question is, what sort of things should I be looking for to get rid of this?

Walter wrote:
> This should help: www.digitalmars.com/bugs.html
> 

Ah, well I was hoping for a hint on what that assertion is checking for so that I could have a general idea of what sort of problem I'm trying to solve. I'm not very clear on what's going on in the context where the assertion fails. At any rate, I'll roll up my sleeves and work it out.

Mike Parker wrote:
> Walter wrote:
> 
>> This should help: www.digitalmars.com/bugs.html
>>
> 
> Ah, well I was hoping for a hint on what that assertion is checking for so that I could have a general idea of what sort of problem I'm trying to solve. I'm not very clear on what's going on in the context where the assertion fails. At any rate, I'll roll up my sleeves and work it out.

You probably already realize this, but the code to the compiler front-end is distributed with the compiler.

In this case, the file involved is dmd\src\dmd\expression.c.

Where the line falls in the code depends on which version of DMD you used.


[Lines 2689-2695] DMD 0.92
    else if (e1->op == TOKvar)
    {
	// Do overload resolution
	VarExp *ve = (VarExp *)e1;

	f = ve->var->isFuncDeclaration();
	assert(f);


[Lines 2689-2695] DMD 0.91
Lcheckargs:
    assert(tf->ty == Tfunction);
    type = tf->next;

    functionArguments(loc, sc, tf, arguments);

    assert(type);


My wild guess is there's a compiler bug with name lookup on a type in a parameter. Or some other parameter type problem. But that's just a guess...


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Mike Parker wrote:
> Walter wrote:
> 
>> This should help: www.digitalmars.com/bugs.html
>>
> 
> Ah, well I was hoping for a hint on what that assertion is checking for so that I could have a general idea of what sort of problem I'm trying to solve. I'm not very clear on what's going on in the context where the assertion fails. At any rate, I'll roll up my sleeves and work it out.

I checked out the code from SVN and was able to cut it down to a small example of what's crashing the compiler. I posted a bug report on it at http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/436

I still don't quite know what's the compiler is choking on, but the example narrows it WAY down.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

J C Calvarese wrote:
> I checked out the code from SVN and was able to cut it down to a small example of what's crashing the compiler. I posted a bug report on it at http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/436
> 
> I still don't quite know what's the compiler is choking on, but the example narrows it WAY down.
> 

Thanks much.

J C Calvarese wrote:

> You probably already realize this, but the code to the compiler front-end is distributed with the compiler.
> 
> In this case, the file involved is dmd\src\dmd\expression.c.
> 
> Where the line falls in the code depends on which version of DMD you used.
> 
> 
> [Lines 2689-2695] DMD 0.92
>     else if (e1->op == TOKvar)
>     {
>     // Do overload resolution
>     VarExp *ve = (VarExp *)e1;
> 
>     f = ve->var->isFuncDeclaration();
>     assert(f);
> 
> 
> [Lines 2689-2695] DMD 0.91
> Lcheckargs:
>     assert(tf->ty == Tfunction);
>     type = tf->next;
> 
>     functionArguments(loc, sc, tf, arguments);
> 
>     assert(type);
> 
> 
> My wild guess is there's a compiler bug with name lookup on a type in a parameter. Or some other parameter type problem. But that's just a guess...
> 

Yes, this is the code that prompted me to post (0.92). What confused me is the isFuncDeclaration() bit. Since the d source file causing the barf is assigning proc addresses to function pointers, my first guess was that this assertion is saying that one of the declared function pointer variables is not valid. That would put the real problem in another module, where the variable is first declared. But that was a wild guess and I was really, really frustrated.

"J C Calvarese" <jcc7@cox.net> wrote in message news:ca88c1$16ph$1@digitaldaemon.com...
> I still don't quite know what's the compiler is choking on,

Declaring a variable has having a function type.