Linking Bug ?

[DavePearce]

The following file causes a NullPointerException in the JavaScriptCompiler (see https://github.com/Whiley/Whiley2JavaScript/issues/62):

method run():
    &int state = new 0

method t(int index):
    std::ascii::to_string(index)

The exception occurs when processing the new expression in constructNew(). My feeling is this must be a bug in typing, since the type of the new expression is void. The weird thing is that we need both run() and t() to get this problem. I don't understand how they are related?

Also, we need build.whiley.library=false.

[DavePearce]

The only realistic hypothesis I've got here is that something goes wrong during NameResolution as we're pulling in all the things needed for to_string(), and this terminates compilation prematurely --- resulting in a WyilFile which has not been typed.

[DavePearce]

So NameResolution is failing, and r becomes false after this line:

try {
  System.out.println("NAME RESOLUTION (" + r + ")");
    r = r && new NameResolution(packages, target, linking).apply();
  } catch (IOException e) {
    // FIXME: this is clearly broken.
    throw new RuntimeException(e);
    }

The problem is that its generating a syntax error on something in the library, rather than the original source file. In other words, its missing some symbols or something. The errors are being generated at the end of NameResolution.Patch.select(). It is confusing because it appears the symbols are there:

SELECT QUALIFIED NAME: std::array::copy : function(T[],uint,T[],uint,uint)->(T[])
FOUND: copy : function(T[],uint,T[],uint,uint)->(T[])       
REJECTED: true and false
FAILED

The REJECTED line suggests the two types are not equals(), even though they appear identical.

[DavePearce]

UPDATE: Those symbol selections which are succeeding are those which don't have nominal types in them.

[DavePearce]

This seems to be a fundamental problem with the way in which elements from different Abstract Syntax Trees are compared. They are currently compared using equals() but, realistically, we want some kind of equivalence. In particular, nominal types use a Ref<T> for the underlying link to the Decl.Named item they refer to. That means they will never be equals() unless they are ==.

This to me suggests that linking in this incarnation of the compiler simply cannot work.

[DavePearce]

Therefore, we need to fundamentally back off from linking.