Community
Participate
Working Groups
(In reply to Stephan Herrmann from bug 537934 comment #31) > (In reply to Till Brychcy from bug 537934 comment #29) > > Unnamed module is added for test sources if the classpath is not empty. > > I see excludeTestCode == false in situations where we don't have any > business looking at test code. Could that flag be set to true much more > aggressively? > > Example: > - CompilationUnitResolver.resolve(..) > - CancelableNameEnvironment(..) > - SearchableEnvironment(.., false) > > If we resolve a CU from main sources, we should really exclude test code, no?
As Stephan referenced this in bug 544017, some thoughts: So far, test class path is excluded for main code during compilation and e.g. completion. The Java model and refactorings always use the full classpath including test dependencies. Pre Java 9 this should not really hurt, as no additional errors are to be expected by seeing more classes. But with Java 9 it may lead to errors if packages become split packages because of this, especially if the unnamed module is involved. Actually I'm not sure if these internally existing, but non-visible errors lead to any visible defects in any tools. Maybe the right classes are still resolved, even if the package is a split package? Anyway, e.g. CompilationUnitResolver.resolve has multiple overloads. In two of them, a CancelableNameEnvironment is constructed, currently always with excludeTestCode=false. The first one talks a simple ICompilationUnit. If we add the necessary info to it, we could set the flag depending on the source folder: org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(ICompilationUnit, IJavaProject, List, NodeSearcher, Map, WorkingCopyOwner, int, IProgressMonitor) The other one takes an array of ICompilationUnit[]. Let's assume they are a mixture of test code and main code. I'm not sure if using two instances of CancelableNameEnvironment here would work at all (if test compilation units reference main compilation units), so probably we'd be back to the current state, where we just use the full classpath for all of them. (But we could probably set excludeTestCode correctly if all of them are either main or test code). So an actual use case where a defect can be seen would be good.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
