NoSuchKey exception of Rascal type checker in some modules

[jurgenvinju]

This NoSuchKey exception seems to be consistent between different modules; so far we've found the following modules that exhibit this bug:

|rascalcore:///lang/rascalcore/check/Checker.rsc|:411,138: NoSuchKey("analysis::statistics::Correlation")

FALSE NoSuchKey(sort("D"))
|file:///Users/paulklint/git/rascal/src/org/rascalmpl/library/lang/rascal/tests/functionality/LayoutTests.rsc|(675,141,<17,0>,<17,141>): FALSE NoSuchKey(sort("C"))
|file:///Users/paulklint/git/rascal/src/org/rascalmpl/library/lang/rascal/tests/functionality/LayoutTests.rsc|(541,133,<16,0>,<16,133>): FALSE NoSuchKey(sort("B"))

|lib://rascal-core/lang/rascalcore/check/RascalConfig.rsc|:310,94: NoSuchKey(|file:///Users/jurgenv/git/rascal-core/src/org/rascalmpl/core/library/lang/rascalcore/check/CollectSyntaxDeclaration.rsc|(3884,1572,<97,0>,<127,1>))

|:310,94: NoSuchKey(|file:///Users/jurgenv/git/rascal/src/org/rascalmpl/library/lang/java/patterns/JavaToMicroPatterns.rsc|(2197,53,<87,0>,<87,53>))

NoSuchKey(|file:///Users/jurgenv/git/rascal/src/org/rascalmpl/library/lang/java/flow/JavaToObjectFlow.rsc|(9357,121,<279,0>,<280,49>)) 

[jurgenvinju]

A new one in rascal-eclipse:

|lib://rascal-core/lang/rascalcore/check/RascalConfig.rsc|:310,119: NoSuchKey(|file:///Users/jurgenv/git/rascal-eclipse-ide/rascal-eclipse/src/org/rascalmpl/eclipse/library/util/IDE.rsc|(4605,238,<138,0>,<140,34>))

[jurgenvinju]

@PaulKlint A plausible diagnosis due to common elements among different instances of this error:

• void collect(current: (Prod) .... (current should have a type!)
• public node stat2outline(l:loop(n, ss)) ... (loop, n and ss should have a type!)

Some of these instances seem to be cause by a pattern variable without a type in a function header. This is not allowed but the interpreter ignores it. It always seems to go wrong with the : notation.

So a combination of issues:

1. the error that the variables in the function headers have no type is not reported?
2. this somehow seems to lead to a downstream lookup failure on the name of the variable?
3. it is connected to the : pattern notation

[jurgenvinju]

On the other hand, the instance in util::IDE does have a type, but does also use the : notation. So perhaps it's just the : notation which triggers the bug:

Contribution proposer(list[CompletionProposal] (&T<:Tree input, str prefix, int requestOffset) prop, type[Tree] cc : type(\char-class(_),_))
  = proposer(prop, class2str(cc));

[jurgenvinju]

it looks to me like some stuff is missing here, which does happen for the "typed variable" case but not for the "variable becomes" cases.

The c.push(patternNames, <uname, name>); does not have getLoc around it for example? And there is a push in the working case which is not in the non-working case?

// ---- variable becomes pattern

void collect(current: (Pattern) <Name name> : <Pattern pattern>, Collector c){
uname = unescape("");
if(inPatternNames(uname, c)){
c.useLub(name, variableRoles);
} else {
c.push(patternNames, <uname, getLoc(name)>);
scope = c.getScope();
c.define(uname, formalOrPatternFormal(c), name, defLub([pattern], AType(Solver s) { return getPatternType(pattern, avalue(), scope, s); }));
}
collect(pattern, c);
}

// ---- typed variable becomes

void collect(current: (Pattern) <Type tp> <Name name> : <Pattern pattern>, Collector c){
uname = unescape("");
c.push(patternNames, <uname, name>);
c.define(uname, formalOrPatternFormal(c), name, defType([tp], AType(Solver s){ return s.getType(tp); }));
c.fact(current, tp);
collect(tp, pattern, c);
}

// ---- typed variable pattern

void collect(current: (Pattern) <Type tp> <Name name>, Collector c){
uname = unescape("");
c.calculate("typed variable pattern", current, [tp], AType(Solver s){ return s.getType(tp)[label=uname]; });
if(uname != "_"){
c.push(patternNames, <uname, getLoc(name)>);
c.define(uname, formalOrPatternFormal(c), name, defType([tp], AType(Solver s){ return s.getType(tp)[label=uname]; }));
}
c.enterScope(current);
collect(tp, c);
c.leaveScope(current);
}

[PaulKlint]

Thanks for the cases + feedback, I have fixed this issue by avoiding it, but not really understanding what the underlying cause is (remains a TODO). The situation is as follows for the case 1-6 above (OK==typechecker completes normally and the above crash does not occur):

1. analysis::statistics::Correlation OK
2. lang::rascal::tests::functionality::LayoutTests: OK
   • renamed to: lang::rascal::tests::concrete::Layout)
3. lang::rascalcore::check::CollectSyntaxDeclaration OK
4. lang::java::patterns::JavaToMicroPatterns OK
   • gives a lot of errors
5. lang::java::flow::JavaToObjectFlow OK
   • gives 3 errors
6. lang::rascalcore::check::RascalConfig OK
   • gives a lot of errors