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

Bug 423987

Summary:	[1.8][assist] Follow up tasks from Bug 422468 - [1.8][assist] Code assist issues with type elided lambda parameters
Product:	[Eclipse Project] JDT	Reporter:	Srikanth Sankaran <srikanth_sankaran>
Component:	Core	Assignee:	Srikanth Sankaran <srikanth_sankaran>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	manoj.palat, stephan.herrmann
Version:	4.4
Target Milestone:	4.5 M4
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Srikanth Sankaran

2013-12-13 02:11:23 EST

This CR will collect the follow up tasks found during code review and testing.

1. We should/could get rid of the new abstraction CommitRollbackParser by
pushing down the APIs into Parser itself.

2. CompletionParser.becomeSimpileParser() and restoreAssistParser() needs
to be studied to see what effect if any they may have on the new commit-rollback
scheme.

3. Stacking of assist nodes can be handled better/cleaner ?

4. We could fast forward past the initial identifiers in an identifier
collection leading up to completion point. 

5. copyState() could avoid deep copy. Note: Parser state stack must be deep
copied. As well as the place in CompletionParser attachOrphanNode(), as the
latter mucks around with expression and ast stacks a bit too much.

6. One more round of review of CommitRollbackParser.

7. AssistParser.resumedAfterRepair: can be handled better. (?)

8. AssistParser.elementStack: do we need lambdas and body kind there - we
don't use it as of now at all.

Comment 1 Srikanth Sankaran

2013-12-15 09:28:59 EST

9. Most important, we should move away from the fake EOF model on completion.

Comment 2 Srikanth Sankaran

2014-11-05 04:21:42 EST

(In reply to Srikanth Sankaran from comment #0)
> This CR will collect the follow up tasks found during code review and
> testing.
> 
> 1. We should/could get rid of the new abstraction CommitRollbackParser by
> pushing down the APIs into Parser itself.

I got rid of CommitRollbackParser by pushing APIs down to Parser or
AssistParser as required here:

http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=cccafe00dbf29f156949d8f0d0aec370b02aa048

> 3. Stacking of assist nodes can be handled better/cleaner ?

This was already implemented.

> 4. We could fast forward past the initial identifiers in an identifier
> collection leading up to completion point. 

This is optional - left alone.

> 5. copyState() could avoid deep copy. Note: Parser state stack must be deep
> copied. As well as the place in CompletionParser attachOrphanNode(), as the
> latter mucks around with expression and ast stacks a bit too much.

This is optional - left alone.

> 
> 6. One more round of review of CommitRollbackParser.

Done and pushed down APIs.

> 7. AssistParser.resumedAfterRepair: can be handled better. (?)

This works as is - left alone

> 8. AssistParser.elementStack: do we need lambdas and body kind there - we
> don't use it as of now at all.

This works as is - left alone

(In reply to Srikanth Sankaran from comment #1)
> 9. Most important, we should move away from the fake EOF model on completion.

This works as is - left alone

Comment 3 Manoj N Palat

2014-12-10 01:28:05 EST

Verified for Eclipse Mars 4.5 M4 using build  I20141209-2000

Comment 4 Stephan Herrmann

2018-08-06 20:11:19 EDT

(In reply to Srikanth Sankaran from comment #2)
> (In reply to Srikanth Sankaran from comment #1)
> > 9. Most important, we should move away from the fake EOF model on completion.
> 
> This works as is - left alone

In bug 473654 I'm chewing on that exact issue.  See there for details.

Comment 5 Stephan Herrmann

2021-04-27 15:38:35 EDT

(In reply to Stephan Herrmann from comment #4)
> (In reply to Srikanth Sankaran from comment #2)
> > (In reply to Srikanth Sankaran from comment #1)
> > > 9. Most important, we should move away from the fake EOF model on completion.
> > 
> > This works as is - left alone
> 
> In bug 473654 I'm chewing on that exact issue.  See there for details.

The final word (so far) in this matter was said via bug 539685, see also https://wiki.eclipse.org/JDT_Core_Programmer_Guide/Completion#Source_code_range