#871 Inherited methods without this shadowed by global functions

[dkl]

It seems like calling foo() without explicit this will prefer a global foo() over an inherited method foo():

sub f()
    print "f"
end sub

type A
    i as integer
    declare sub f()
end type

sub A.f()
    print "A.f"
end sub

type B extends A
    declare sub test()
end type

sub B.test()
    f()
end sub

dim bb as B
bb.test()

Prints:
f
Expected:
A.f

I think it should prefer the inherited method, since the this is implicit inside methods. The global should be reachable through the special . operator for accessing the global namespace instead.

[dkl]

possibly related: [#581], [#645]

[Jeff Marshall]

First look at this bug and we certainly find it's in the same area of the compiler as [#645] and [#581]. The cause is a little different.

Changing the order of the functions in the original example source produces the correct look-up:

type A
    i as integer
    declare sub f()
end type

sub A.f()
    print "A.f"
end sub

type B extends A
    declare sub test()
end type

sub B.test()
    f()
end sub

sub f()
    print "f"
end sub

dim bb as B
bb.test()

/'
Prints:
A.f
Expected:
A.f
'/

We are getting the correct symbols on the symbol chain when it is looked up in the symbol database, but in this scenario we should not expect the called function to be dependent on the order of definition. And causes a problem of not being able to call ..f() from B.test() because then there is no way to declare the global f() procedure before it is referenced.

[Jeff Marshall]

fixed in fbc 1.09.0
commit: [c2f08a6be9c09700043ec6cfeb37156a5db97514]

Changes to fix this bug also fix [#730]