Euphoria Ticket #343: -TEST -D SAFE socket.e picks wrong info()

this appears even when socket tested safe alone.

eui -TEST -STRICT -D SAFE socket.e 
include\std\socket.e:341 
<0132>:: Syntax error - expected to see possibly ')', not a variable 
sequence sockinfo = info(ESOCK_TYPE_AF) 
                                 ^ 

some kind of forward reference bug?

info() is defined later in sockets.e and appears in safe.e via std/machine.e

Details

Type: Bug Report Severity: Normal Category: Interpreter
Assigned To: mattlewis Status: Fixed Reported Release: 3981
Fixed in SVN #: 3990, 4014, 4031, 4032, 4082, 4174, 4186, 4210, 4211 View VCS: 3990, 4014, 4031, 4032, 4082, 4174, 4186, 4210, 4211 Milestone: 4.0.0RC2

1. Comment by mattlewis Nov 09, 2010

It's not necessarily a forward referencing bug per se. There is a public info() function in safe.e that is in scope before the info() function in socket.e is parsed. The safe.e version is commented, "Shawn's custom stuff," which leads one to wonder if we need it there.

There are a couple of ways to handle this. First, we could probably use a namespace qualifier. Alternatively, we could defer resolving any unqualified symbols until we've parsed the entire file. This would ensure that local symbols always overrode external symbols when used in an unqualified manner. That's probably a cleaner thing to do, though it will certainly slow down the parsing process.

2. Comment by DerekParnell Nov 09, 2010

My expectation is that local unqualified overrides external symbols, and resolving them I thought was already being done after the entire file is parsed.

3. Comment by mattlewis Nov 09, 2010

I'll take a look...

4. Comment by SDPringle Nov 09, 2010

Just as any other conflict of symbols, the error should be namespace required... However, based on the number of arguments alone it is easy to see which function should have been called. Why can't the parser do that?

5. Comment by DerekParnell Nov 09, 2010

I'm sure that parser can be made to do that, plus resolve calls based on argument signatures too. However, that won't be happening for a couple of releases yet, I suspect.

6. Comment by mattlewis Nov 09, 2010

This should not require a namespace to resolve. Looking at parameters to resolve symbols adds a lot of complexity, and wouldn't affect constants or variables.

7. Comment by mattlewis Nov 19, 2010

Resolution is now deferred until we have all of the information required to figure it out.

Search



Quick Links

User menu

Not signed in.

Misc Menu