Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 327191

Summary: Additional information in content-assist shows up only for types, not for functions
Product: [WebTools] JSDT Reporter: Jacek Pospychala <jacek.pospychala>
Component: GeneralAssignee: Jacek Pospychala <jacek.pospychala>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: normal    
Priority: P3 CC: cmjaun
Version: 3.2.2Flags: thatnitind: review+
cmjaun: review+
Target Milestone: 3.2.3   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
screenshot
none
patch
none
patch v2
none
patch v2 alternative thatnitind: iplog+

Description Jacek Pospychala CLA 2010-10-07 04:46:41 EDT
Given following code:

/**
 * Returns the sum of a and b.
 */
function sum(a, b) {
	return a + b;
}

/**
 * Summarizer
 * 
 * @constructor
 */
function Sum() {
	
}

After invoking content-assist, for e.g. "su", you should see three proposals: sum(a, b), Sum as type as Sum() function call. 
Additional information with jsdoc appears only for Sum as type and not for functions.
Comment 1 Jacek Pospychala CLA 2010-10-07 04:53:08 EDT
Created attachment 180397 [details]
screenshot
Comment 2 Jacek Pospychala CLA 2010-10-07 05:29:56 EDT
the problem is somewhere in MethodProposalInfo.resolveMember().
Trying to find enclosing type of a method results with null:

javaProject.findType("/p/aa.js") returns null
"/p/aa.js" is the name of file in this case, because methods are declared directly in file.
Comment 3 Jacek Pospychala CLA 2010-10-07 06:06:21 EDT
Created attachment 180405 [details]
patch

It's caused by changes to bug 316327
Proposed changes in MethodProposalInfo.resolveMember():
1. construct like below will never enter the loop. So I modified loop a bit.

IFunction func = null; 
for(int i = 0; i < types.length && func != null; ++i) { ... loop... }

2. javaPropect.getTypes(typeName) can return 1-element array with null, when type was not found. In this case it's worth trying also javaProject.findTypeRoot(typeName), so I removed "else".
Comment 4 Jacek Pospychala CLA 2010-10-07 06:08:08 EDT
Take a look at this patch guys.
Comment 5 Nitin Dahyabhai CLA 2010-10-07 18:20:27 EDT
Don't we get the same result by fixing the for loop so the condition is "i < types.length && func == null" ?
Comment 6 Jacek Pospychala CLA 2010-10-08 03:33:28 EDT
yes, this works as well.
but there's still need to support calling javaProject.findTypeRoot() if javaProject.findTypes() returned IType[1] {null}.
Comment 7 Jacek Pospychala CLA 2010-10-08 03:34:05 EDT
Created attachment 180475 [details]
patch v2

improved patch
Comment 8 Jacek Pospychala CLA 2010-10-08 03:43:09 EDT
btw. probably it's a separate issue that javaProject.findTypes() sometimes returns IType[1] {null}. It should return null instead.
Comment 9 Jacek Pospychala CLA 2010-10-08 03:44:43 EDT
Created attachment 180476 [details]
patch v2 alternative

Different patch, that fixes problem with returned value in javaProject.findTypes(name) and changes "!=" to "==" in MethodProposalInfo.
Comment 10 Nitin Dahyabhai CLA 2010-11-17 18:06:22 EST
Nice fix, Jacek, thanks!