congo-cc
Synching up the error reporting functionality for non-Java languages
I (VERY) recently made a big push to get error reporting in better shape, but all of the changes were exclusively on the Java side. I really just don't have the skills to keep it all working the same in Python or CSharp.
To get a feeling for what is going on, try this test file:
public class Foobar {
void foo() {
foobar()++;
++this;
x = 7++;
this = 7;
7++;
-8;
x + 3;
(x()++);
x?y:z = t;
}
}
Well, obviously, every single line in the foo() method above is invalid, i.e. not a valid statement in Java. But the interesting issue is the error reporting. Based on the latest 'master', if you build the Java parser and run it on the above file, Foobar.java presumably, you get the picture. The error reporting (but only with the Java parser) is quite radically improved. You can see what it reports for each of the lines by moving the specific line to the top and rerunning java JParse Foobar.java.
This is quite a bit better than the error reporting previously. But again, only for the Java parser. The error reporting for C# is pretty cryptic and crappy. BUT it does fail at all the points where it is supposed to fail and it should not be too hard (if you know C# anyway) to get this working on a par with the Java parser.
With Python, the situation is more disturbing. The Python parser parses the first 5 lines with no complaint. It seems that the whole check for whether the relevant expressions are "assignableTo" is broken. And I don't know whether that is recent or it has been that way for a long time. (I'm betting it's the latter but I'm not 100% sure.)
Well, anyway, I need help! Maybe somebody whose initials are VS will get this error-checking working. Particular, the Python situation is horrible.
By the way, I think the way this should work is as follows. The person who gets this working (presumably with the initials VS but even if those are not the person's initials...) should write a brief explanation of why this was not working and what he (or maybe she!?) had to do to get it working, again in plain English. Because I really want to gradually improve my mastery of the situation to where I can address most of these things myself. But it's going to be gradual. If I don't have help to keep the non-Java languages in synch, I may have to abandon the whole polyglot venture.
BTW, the reason that the python parser was accepting things like 7++ or 3=x while the other ones were not is actually quite diabolical.
You see, the basic thing is that if we have an assignment like lhs = expression sort of thing, the lhs, i.e. left-hand-side must be "assignable", right? It can't just be 7 or x() or something like that. It needs to be a proper variable. The same for postfix or prefix expressions, like ++x or something. That is just shorthand for x=x+1; so the LHS is x which needs to be assignable. So 7++ is not a valid assignment, since the expression 7 is (obviously) not assignable.
What happened, though, is that the check like lhs.isAssignableTo() was, via some (spurious) name munging, getting generated as: lhs.is_assignable_to (instead of lhs.is_assignable_to()) and then, given this sort of truthiness logic in Python, the expression lhs.is_assignable_to was just interpreted as always being true in a boolean (or truthy) context. Ergo, the lhs was always assignable and it accepted things like 7=x.
I fixed it by simply changing isAssignableTo to canBeAssigned and then it worked! Why? Because with a function name that did not start with "is", it didn't do any funny stuff (or less, anyway) and it ended up dealing with `ASSERT {lhs.canBeAssigned() : "LHS is not assignable"} properly. That fixed it, but of course, there is a real problem here!
OK, this is probably a transpiler issue and I'll look at it as soon as time permits.
Well, yeah. It's definitely a transpiler issue and not the only one I've run into over the past couple of weeks.
Look, I think we really need to take a step back on certain things and have the transpiler stuff be more conservative. For example, if something is a java.util.List on the Java side, okay, it makes perfect sense for list[n] to work on the Python side as a natural "python-ish" way of writing list.get(n). That is a question (AFAICT) of having the right "dunder" methods defined. BUT... I don't think that an attempt to have these things happen automatically makes much sense. At least, I have to say that I just don't have the feeling that it is reliable enough. So, if we have node.get(i) on the java side, it should not be automatically translated to node[i] or any of that. I think it's very problematic. I don't think that making the generated code in other languages more idiomatic really buys us much.
So my preferred solution (for now, anyway) is to limit the magical renaming quite a bit. If something is getFoo() on the Java side, the name of the method in C# and Python should be getFoo(), not get_foo() or GetFoo(). Now, I guess that automatically defining the properties is not necessarily bad, but I think that trying to rename everything automatically has not turned out terribly well. Eventually, we'll have the ability to inject Python and C# code directly into the code, so yes, having the more natural coding pattern working would be a good thing. But I don't think that trying to automatically translate all these things is good. If a Java code action or assertion or whatever has getSource() or getLocation() it should just be that on the non-Java side.
Of course, I recognize that certain translations are necessary, like toString() does have to be changed to ToString() for C# and has to be str()orrepr()` (not sure) in python) but those are necessary. I'd just prefer to limit the magical renamings down to what is absolutely necessary.