ClassHierarchy branch errors resolving variables. #47
Comments
|
JetBrains branch doesn't have such problems. I think this should be related to PSI changes you guys made. |
|
OK. I'll take a look. |
|
Also there is an error if there are two It works fine in JetBrains branch, but errors out with |
|
grisevg wrote:
Opened a new issue #48. |
EBatTiVo
changed the title
|
TiVo Internal Reference: STB-5073 |
|
|
When I type something following error occurs together with mentioned above one: |
|
Also it seems like unit tests need to be updated too. |
|
<> Unit Tests? What are those? <> Actually, I haven't run them. (I've been in such a hurry to get stuff working.) It's a good idea to keep them up to date. I'll check them and make sure they work when I figure this out. As far as the exceptions go, I thought I fixed the one in HaxeMethodPsiMixinImpl.isPrivate(). I've seen it before. I'm fully synched up, so it must be a different path to the same problem. |
|
Yeah, it's Great. I will test. Previously I was getting some errors related to HaxeElementName or something, which used to tell that get name returns null, but it shouldn't be null. |
I'm unable to find related commit in ClassHierarchy branch of your repository. |
|
So perhaps those things stop us from making stable release. |
|
The error was introduced by change aa854a6. The "statement" rule in haxe.bnf was no longer private. That added new "statement" psi constructs around a number of elements. Most importantly, for our current conundrum, the ASSIGN_DECLARATION and the LOCAL_VAR_DECLARATION elements. The algorithm that searches for local variables simply looked at the next level up (recursively) in the hierarchy when looking for a declaration to resolve to. Now that we've added the extra layer, the variable declaration isn't found; the STATEMENT element is, and it doesn't match the search type, so the element is skipped. One way out would be to make the STATEMENT element private again in the BNF. That brings along a number of other issues, the primary one being that we need a realization of the HaxeStatementImpl class in order to implement HaxeBlockStatementPsiMixin and HaxePackageStatementPsiMixin (and their respective Impl classes). And we need these to so that we have a class of the type PsiCodeblock to interoperate with some of the Java language functionality. Another potential implementation is to traverse back down one level in the traversal algorithm when we see a STATEMENT element. The algorithm is fairly generic right now, so this will force some specialization. The code that would have to change is PsiTreeUtil.treeWalkUp(). |
…ent' element in grammar/haxe.bnf private again. This removed the intermediate 'STATEMENT' elements from the Psi, and allowed the references to be found naturally by walking up the tree. To get variable names in for loops to resolve, added a new HaxeForStatementPsiMixin interface and impl class. The new class was needed because for statements still need to be PsiStatements (via HaxeStatement) and need to the AbstractHaxeNamedComponents for the resolution logic to work.
|
Fixed with c65b928. Repair variable name resolving (TiVo/#47). To do so, made the 'statement' Test program I was using: package ;
import as.be.sed;
class QuickResolveTest {
public function new() {
var longerVarName:Int;
longerVarName = 1;
for (forLoopVar in 1...10) {
var internalToForLoop: Int
internalToForLoop = forLoopVar;
}
var even_numbers = [for (i in 1...10) i * 2];
trace (even_numbers)
}
public function test1(param1:Int, param2:Float, param3:String) {
++param1;
trace (param1);
trace (++param2);
trace (param3)
}
}
|
|
Yes! Thank you! |
ClassHierarchy has broken variables resolving
Even simple
The text was updated successfully, but these errors were encountered: