-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiler exception due to mismatch between JavaParser and javac #6630
Comments
I'm encountering an issue where the code is crashing at an assert statement in public class Test {
ArrayList<Qw> qws = new ArrayList<Qw>();
public static void main(String[] args) throws FileNotFoundException, UnsupportedEncodingException {
// ....
}
} This class has two members. While JavaParser correctly identifies these members, Javac does not detect any members. To debug this issue, I tracked where the class members might be getting lost in Javac. Here is the trace I followed:
In root.accept(new AjavaAnnotationCollectorVisitor(), cu); Following this, the I need help locating the specific invocation of |
@smillst, could you please provide your expertise on this matter? |
I tried the reproducer, but did not get the crash. Can you make a smaller example the reproduces the crash? |
After thorough investigation, I am closing this issue as I was unable to reproduce it on other machines. The original issue was encountered on a Linux machine. However, after testing on a new Linux machine with the same configuration and cleaning the metadata on the original machine, the issue did not recur in either case. |
I've encountered this compiler crash again in some projects in the NJR benchmark. This time I could reproduce it in my local maching (M2 mac). Also, @msridhar was able to reproduce it as well.
I'm attaching a google drive link with the updated script and project (project was too large to upload into GH): https://drive.google.com/file/d/1rXsOIEmjSj2D1siZ4TzjD8R7I8_fWwC4/view?usp=sharing To run:
|
I can reproduce the problem with the new reproduction package and I'm looking into it. |
I've spent the last few hours investigating this problem, and it seems very serious to me. I'm writing notes here to both document my progress and hopefully get some ideas from others (@msridhar and @mernst, in particular) about where we might look next. The stack trace indicates that
The problem occurs when processing the compilation unit for I traced this emptiness all the way up the stack trace; in The question is what we should do about it. Here are some possibilities:
I can reproduce this behavior with any typechecker (I was concerned because the stack trace does include I can reproduce the behavior with Java 11 and with Java 21, so if this is a javac bug, it's been there for a long time. |
This is indeed surprising. I looked over the @kelloggm is it the case right now that if there is code that should trigger a checker error within |
@kelloggm I did a bit more debugging of this case and here is what I found. |
@msridhar thanks for digging into this. The behavior that you've described definitely explains the bug.
I agree with your analysis. This is only a problem for WPI because we wrote assertions that require the javac AST and the AST parsed from the I have two remaining concerns:
On the first point, I wrote an
To my surprise, this test does trigger the weird javac behavior but does not trigger a crash. There is a call to
Note how this compilation unit has |
I've confirmed my hypothesis that the crash is triggered by the extends clause, with the following test (with two files):
This causes the same assertion error that was previously reported when added to one of the |
I think the problem is that So, if we move the calls to Is this only a problem when |
Ok, I see that in the reproduction that @iamsanjaymalakar supplied, -AajavaChecks isn't used and this is still a problem. That crash is triggered in
Can you change |
Encountered it while running CF on the NJR benchmark.
Stacktrace
Reproducer
reproducer.zip
CF_ROOT
path inwpi.sh
.The text was updated successfully, but these errors were encountered: