#16 Unresolved name

closed-fixed
None
5
2003-02-18
2003-01-18
Bryn Keller
No

Using Nice compiler version 0.7.6 (build 2003.01.17,
00:42:24 UTC):

package compilerbug;

class A {
String name;
A a() {
return toA([name]);
}
}

A toA(Collection<String>) = new A();
//<T> A toA(Collection<T> coll) = new A();

Gives:

An exception has occured in the compiler
Please fill-in a bug report at the following webpage:
http://sourceforge.net/tracker/?func=add&group_id=12788&atid=112788

Exception: bossa.util.InternalError:
.\compilerbug\compilerbug5.nice: line 6, co
lumn 17:
name has not been resolved yet.
Possibilities are :
[java.lang.String name(compilerbug.A)
|?java.lang.String name(java.lang.ThreadGroup) = native
java.lang.ThreadGroup.name;]

Stack trace:

bossa.util.InternalError:
.\compilerbug\compilerbug5.nice: line 6, column 17:
name has not been resolved yet.
Possibilities are :
[java.lang.String name(compilerbug.A)
|?java.lang.String name(java.lang.ThreadGroup) = native
java.lang.ThreadGroup.name;]
at bossa.util.Internal.error(Internal.java:82)
at bossa.util.Internal.error(Internal.java:69)
at
bossa.syntax.OverloadedSymbolExp.computeType(OverloadedSymbolExp.java:377)
at
bossa.syntax.Expression.getType(Expression.java:136)
at
bossa.syntax.Expression.getType(Expression.java:172)
at
bossa.syntax.LiteralArrayExp.computeType(LiteralArrayExp.java:48)
at
bossa.syntax.Expression.getType(Expression.java:136)
at
bossa.syntax.Arguments.computeTypes(Arguments.java:119)
at
bossa.syntax.OverloadedSymbolExp.resolveOverloading(OverloadedSymbolE
xp.java:89)
at
bossa.syntax.CallExp.resolveOverloading(CallExp.java:242)
at
bossa.syntax.CallExp.computeType(CallExp.java:247)
at
bossa.syntax.Expression.getType(Expression.java:136)
at
bossa.syntax.fun.typecheck(~/Nice/src/bossa/syntax:104)
at
bossa.syntax.dispatch.typecheck(~/Nice/classes/bossa/syntax)
at
bossa.syntax.fun.typecheck(~/Nice/src/bossa/syntax:535)
at
bossa.syntax.dispatch.typecheck(~/Nice/classes/bossa/syntax)
at
bossa.syntax.fun.lambda16(~/Nice/src/bossa/syntax:433)
at bossa.syntax.fun.apply1(~/Nice/src/bossa/syntax)
at
gnu.expr.ModuleMethod.apply1(ModuleMethod.java:89)
at
nice.lang.fun.foreach(~/Nice/stdlib/nice/lang:91)
at
nice.lang.dispatch.foreach(~/Nice/classes/nice/lang)
at
bossa.syntax.fun.typecheck(~/Nice/src/bossa/syntax:431)
at
bossa.syntax.dispatch.typecheck(~/Nice/classes/bossa/syntax)
at
bossa.syntax.ToplevelFunction.innerTypecheck(ToplevelFunction.java:120)
at
bossa.syntax.MethodDeclaration.typecheck(MethodDeclaration.java:147)
at bossa.syntax.Node.doTypecheck(Node.java:342)
at bossa.syntax.Node.doTypecheck(Node.java:346)
at bossa.syntax.Node.doTypecheck(Node.java:346)
at bossa.syntax.AST.typechecking(AST.java:121)
at
bossa.modules.Package.typecheck(Package.java:275)
at bossa.modules.Package.compile(Package.java:224)
at
mlsub.compilation.fun.lambda23(~/Nice/src/mlsub/compilation)
at
mlsub.compilation.fun.apply1(~/Nice/src/mlsub/compilation)
at
gnu.expr.ModuleMethod.apply1(ModuleMethod.java:89)
at
nice.lang.fun.foreach(~/Nice/stdlib/nice/lang:91)
at
nice.lang.dispatch.foreach(~/Nice/classes/nice/lang)
at nice.lang.fun.iter(~/Nice/stdlib/nice/lang)
at
mlsub.compilation.fun.compileComponent(~/Nice/src/mlsub/compilation:36)
at mlsub.compilation.fun$make.lambda19(Unknown
Source)
at mlsub.compilation.fun$make.apply1(Unknown
Source)
at
gnu.expr.ModuleMethod.apply1(ModuleMethod.java:89)
at
nice.lang.fun.foreach(~/Nice/stdlib/nice/lang:91)
at
nice.lang.dispatch.foreach(~/Nice/classes/nice/lang)
at nice.lang.fun.iter(~/Nice/stdlib/nice/lang)
at
mlsub.compilation.fun.make(~/Nice/src/mlsub/compilation:52)
at
nice.tools.compiler.fun.compile(~/Nice/src/nice/tools/compiler:37)
at
nice.tools.compiler.fun.compile(~/Nice/src/nice/tools/compiler:160)
at
nice.tools.compiler.fun.main(~/Nice/src/nice/tools/compiler:177)

Discussion

  • Arjan Boeijink
    Arjan Boeijink
    2003-01-18

    Logged In: YES
    user_id=688815

    It is a bug that the compiler throws an exception instead of
    printing an error message.
    You found a case where you still need to use 'this' to access
    a field.
    It's possible to make the 'this' superfluous but that doesn't
    have any priority.
    A working alternative:
    class A {
    String name;
    A a() = toA([this.name]);
    }
    A toA(Collection<String>) = new A(name: "abc");

     
  • Bryn Keller
    Bryn Keller
    2003-01-29

    Logged In: YES
    user_id=2706

    I have a (large) sample where this error occurs when it
    really shouldn't. Unfortunately, I haven't been able to
    duplicate it in a small test case yet, but the basic
    situation is this:

    Nice package A defines some symbol, call it Foo.

    Java package B also defines a Foo. (Not even class Foo, just
    an int member variable)

    Nice package C uses (even without import) B.

    Nice package D imports A and C.

    The compiler complains it can't tell whether you mean A.Foo
    or B.Foo, and telling it you mean A.Foo gives another error.

    I'll continue to try to work up a good test case, but I
    thought I should mention it now so it doesn't get forgotten.

     
  • Daniel Bonniot
    Daniel Bonniot
    2003-02-18

    • assigned_to: nobody --> bonniot
    • status: open --> closed-fixed
     
  • Daniel Bonniot
    Daniel Bonniot
    2003-02-18

    Logged In: YES
    user_id=88952

    This bug is fixed in CVS and in the development version.

    Bryn, what about this other error? At first sight, it does
    not seem related to this one (internal error VS ambiguity
    error message).
    So I close this bug, because it is fixed.

    Please try to provide a test case for the other one, so we
    can work on it. Then we can see if it is a bug or not.

    One thing to keep in mind about overloaded symbols is that
    they get resolved by
    1) the type of the values they are applied too (for
    functions/methods).
    2) the type of the variable they are assigned too.
    If you use an overloaded symbol in an other context, like
    [foo], the compiler has no idea which one you are speaking
    about, and gives an ambiguity. Is this the case of your
    second error?