Bug 562056 - Cannot evaluate expressions in JSR-45 adopted classes
When debugging Xtext based DSL with Java sources generated from DSL,
evaluations of expressions in context of the lambda frames no longer
work.
The class files generated by compiler from Java sources (that are
generated from DSL sources) are changed by Xtext to contain source line
information that matches original DSL sources, and not Java sources (see
JSR-45 https://jcp.org/en/jsr/detail?id=45).
Under these conditions, line numbers provided by JDIStackFrame do not
match actual compilation unit lines and so
JDIStackFrame.LambdaASTVisitor.visit(LambdaExpression) will not be able
to adjust captured lambda variable names to be human readable form (the
method will return without doing anything). So the fix for bug 561542
will not work, causing the fix for bug 560392 to produce a broken
variable name.
E.g. evaluation engine will try to create & evaluate expression that
contains variable name "1" instead of "arg$1". The invalid variable name
causes compilation error that prevents evaluation of the expression.
This change fixes lambda captured variable names resolving while
debugging code generated from non-Java source code and avoids errors
while evaluating expressions in context of such code:
- we do not try to resolve captured variable names from Java sources if
we know the code was not written in Java,
- we do not apply the fix for bug 560392 if real names of captured
lambda variables are not provided.
Note: both tryToResolveLambdaVariableNames() and isProbablyJavaCode()
are made protected for non-Java based debugger implementations, in case
they want provide this information from their languages.
Change-Id: Ifa6ef1baa8a72a4a811d2dfe4526be38c422f1f4
Signed-off-by: Simeon Andreev <simeon.danailov.andreev@gmail.com>
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
5 files changed
