-
-
Notifications
You must be signed in to change notification settings - Fork 352
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
fix: Search for packages in all available Java modules #3771
fix: Search for packages in all available Java modules #3771
Conversation
This is very odd. If I now run all tests locally with IntelliJ IDEAs test runner, I get a test failure on
If I run that test individually, it does not fail. If I run all tests with Maven, there are no failures either. Similarly, there's no failure in CI. Something odd is going on with that test, and I can't see how it's related to the changes I just performed. EDIT: This appears to be a problem with IntelliJ IDEA's test runner, in combination with use of the nested test classes in |
These are not tests of the module itself, but simply that other components behave correctly in modules
Ready for review. |
This is a serious bug! I'm not that surprised given the relatively low usage of modules in the field. The fix LGTM, thanks @slarse ! |
Indeed! I'm hoping this solves the most severe issues we're facing in Sorald. But I have a nagging feeling this isn't the last module-related bug we'll see. It's just such a significant metamodel shift from the pre-Java 8 times. |
@monperrus Think this could be merged today? It's a blocker for handling Java 9+ projects with Sorald. |
Very important fix wrt modules, thanks a lot @slarse |
Fix #3769
The issue describes the symptoms and the root cause of them. The tl;dr is that
PackageFactory.get(String)
only searches for packages in the unnamed module, causing type resolution in named modules to not work correctly. This PR fixes that by searching for packages in all modules.As noted in #3769, there's probably a whole lot of code that assumes that there's only the unnamed module, and therefore use
CtModel.getRootPackage()
(which returns the root package of the unnamed module) as the definitive root package, which as of Java 9 is not appropriate.