www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - expression.c assertion failure

reply Mike Parker <aldacron71 yahoo.com> writes:
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?
Jun 09 2004
parent reply "Walter" <newshound digitalmars.com> writes:
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?
Jun 09 2004
parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
Jun 09 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jun 09 2004
parent Mike Parker <aldacron71 yahoo.com> writes:
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.
Jun 10 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jun 09 2004
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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.
Jun 10 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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.
Jun 10 2004