Shadowing of higher-order function names is incorrect

[rodinaarssen]

Describe the bug

While bringing rascal-lucene up to date with the latest Rascal release, I stumbled upon a situation where the name of a higher-order function was not resolved correctly. I've tried to make this report as concise as possible, but I'm afraid it's still rather large.

The module analysis::text::search::Grammars contains a function isToken (of type bool(Tree)) and a function tokens (with signature list[Tree] tokens(Tree tok, bool(Tree) isToken). Note that the name isToken appears in two scopes. When calling the latter function with yet another function as parameter (i.c.: isComment), the isToken function that was called inside the tokens function did not resolve to isComment, but to (the global) isToken instead.

To Reproduce

1. Open the rascal-lucene project (v0.1.0) in VS Code with version 0.13.0 of the Rascal extension.
2. Start a REPL in this project and execute the following and observe that the output of the final two function calls is the same (isComment was executed in both calls to tokens).

import IO;
import ParseTree;
import lang::pico::\syntax::Main;
import analysis::text::search::Grammars;
l = |project://rascal-lucene/src/analysis/text/search/testdata/Fac.pico|;
pt = parse(#start[Program], readFile(l));
tokens(pt, isComment)
tokens(pt, isToken)

3. Start a new REPL and execute the same commands, swapping the final two. Again, observe that the output is equals; however, it is not the same as in the previous step ((the global) isToken was executed in both calls to tokens).

Expected behavior
The output of these function calls should not be equal.

Desktop (please complete the following information):

• VS Code 0.13.0

Additional context

• This behavior was introduced between Rascal 0.41.0-RC76 and 0.41.0-RC77. In this time, caches around resolution of function names were introduced.
• I suspect that the caching around the resolution of isToken and/or isComment is too eager/faulty.

[DavyLandman]

@jurgenvinju I think this fits in your alleyway, for when you're back from holiday.

[jurgenvinju]

Yep. Excellent report @rodinaarssen @DavyLandman thanks.

Note to self:

• The administration of whether a function is final or not, and so if it can be cached is on the ModuleEnvironment level.
• It looks like the name is found on the module level in this administration, even if the actual function is found in the nested scope.
• That way caching is activated for the lookup of a function in a CallOrTree expression, even if the function is a dynamic parameter.
• And so you get funny effects. Even if your next test passes in a different function, you get the previous behavior, but only if you didn't call the function first yourself. In that case you get what you expected.
• We can see this by running the tests of lucene in different orders, and making different tests fail because of this.