Investigate flaky ContentAssistTest

[cdietrich]

Investigate flaky ContentAssistTest
i wonder if there was a change in platform that might increase a general problem in xbase
@iloveeclipse @szarnekow were there changes in JDT search recently (4.30)?

[iloveeclipse]

The search was split into two ui/core bundles

[cdietrich]

it looks like

BasicSearchEngine searchEngine = new BasicSearchEngine();
		searchEngine.searchAllTypeNames(
				packageName, SearchPattern.R_PATTERN_MATCH, 
				typeName, SearchPattern.R_PREFIX_MATCH | SearchPattern.R_CAMELCASE_MATCH, 
				filter.getSearchFor(), scope, 
				new IRestrictedAccessTypeRequestor() {
					@Override
					public void acceptType(int modifiers, char[] packageName, char[] simpleTypeName,
							char[][] enclosingTypeNames, String path, AccessRestriction access) {
						if (dirtyTypenameFilter.accept(modifiers, packageName, simpleTypeName, enclosingTypeNames, path) && 
							filter.accept(modifiers, packageName, simpleTypeName, enclosingTypeNames, path) && (!checkAccessRestriction() || (access == null || access.getProblemId() != IProblem.ForbiddenReference && !access.ignoreIfBetter()))) {
							StringBuilder fqName = new StringBuilder(packageName.length + simpleTypeName.length + 1);
							if (packageName.length != 0) {
								fqName.append(packageName);
								fqName.append('.');
							}
							for(char[] enclosingType: enclosingTypeNames) {
								/*
								 * the JDT index sometimes yields enclosingTypeNames in the form
								 * char[][] { { Outer$Middle } }
								 * rather than
								 * char[][] { { Outer }, { Middle } }
								 * thus we create the fqName as the binary name and post process the proposal later on
								 */
								fqName.append(enclosingType);
								fqName.append('$');
							}
							fqName.append(simpleTypeName);
							String fqNameAsString = fqName.toString();
							createTypeProposal(fqNameAsString, modifiers, enclosingTypeNames.length>0, proposalFactory, myContext, scopeAware, jvmTypeProvider, valueConverter);
						}
					}
				}, 
				IJavaSearchConstants.WAIT_UNTIL_READY_TO_SEARCH, 
				new NullProgressMonitor() {
					@Override
					public boolean isCanceled() {
						return !acceptor.canAcceptMoreProposals();
					}
				});

randomly does not return anything

[cdietrich]

maybe the wait is not working anymore

[cdietrich]

might be a race between

InitializeAfterLoadJob$RealJob.run(IProgressMonitor) line: 39	
Worker.run() line: 63	

and

BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int, IJavaSearchScope, boolean, IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 1809	
BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int, IJavaSearchScope, IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 1751	
SearchEngine.searchAllTypeNames(char[], int, char[], int, int, IJavaSearchScope, TypeNameRequestor, int, IProgressMonitor) line: 1100	
JavaCore.updateLegacyIndex(IProgressMonitor) line: 4749	
JavaCore.initializeAfterLoad(IProgressMonitor) line: 4697	
JavaProjectSetupUtil.createJavaProject(String, boolean) line: 124	
JavaProjectSetupUtil.createJavaProject(String) line: 116	

this might break the performConcurrentJob

	 * Note: multiple thread might attempt to perform concurrent jobs at the same time,
	 *            and should synchronize (it is deliberately left to clients to decide whether
	 *            concurrent jobs might interfere or not. In general, multiple read jobs are ok).

[cdietrich]

badcase.txt
goodcase.txt

[cdietrich]

unfortunately i wont have time to debug this further.
really wonder why search in jdt no longer works reliably
@iloveeclipse can you let your language team do an assesment on how they might be affected
(problem will affect all xtext based languages that use jdt search based proposals

[cdietrich]

am not sure if something like

@BeforeClass
@BeforeAll
public static void setUp() throws Exception {
	Job.getJobManager().join(JavaUI.ID_PLUGIN, null);
	javaProject = JavaProjectSetupUtil.createJavaProject("contentAssistTest");
	JavaModelManager.getIndexManager().waitForIndex(true, null); //maybe need also before creation?
}

would help in all cases. unfortunately on stupid ci much more likely to reproduce

it does not help => i am clueless

[cdietrich]

will ignore the test for now. have no time to investigate in jdt