Bug 454956

Comment 1 Marcel Bruch 2014-12-12 02:36:42 EST

would be surprising since there is no logic to remove quick fixes...

Since this is an Eclipse built-in snippet, which version of Eclipse are you using?

Comment 2 Peter Platek 2014-12-13 14:39:10 EST

eclipse.buildId=4.4.1.M20140925-0400

Comment 3 Marcel Bruch 2014-12-15 12:48:11 EST

Tested on Eclipse Standard/SDK Version: 4.4.1, 4.5 M3 and I don't see any problem with CTRL+1 on iterables.


Test snippet:


package test;

import java.util.List;

public class Test {

    void s(List<String> ss){
        ss|<ctrl+1, select the enhanced for each loop>
    }
}


Closing as invalid. Please reopen if there is anything in the logs that makes you certain that Code Recommenders actually prevents you from having this snippet. I yet don't know anything in Code Recommenders that can have that side effect - but I'd be happy if you could prove me wrong and found a bug.

Comment 4 Peter Platek 2014-12-15 22:23:25 EST

Created attachment 249452 [details]
What happens when you have something after the interable

Comment 5 Peter Platek 2014-12-15 22:28:08 EST

Looks like when you have a something after the iterable and it gets underlined it will show you the selection in the attachment.

I used this code to test:

package test;

import java.util.List;

public class Test {
    
	void s(List<String> ss){
        ss
        
        String something;        
    }
	
}

However this shows what is expected:

package test;

import java.util.List;

public class Test {
    
	void s(List<String> ss){
        ss
        
        int i;
        
    }
	
}

Comment 6 Marcel Bruch 2014-12-16 09:14:56 EST

(In reply to Peter Platek from comment #5)
> Looks like when you have a something after the iterable and it gets
> underlined it will show you the selection in the attachment.

I can confirm that the above example does not work while the second one works as announced in an IDE where code recommenders is installed. However, I also tested this scenario with the JEE package (where Code Recommenders is not included) and got the same behavior. Thus, I don't see how Code Recommenders can cause this yet. Are you still convinced Code Recommenders causes this?

Comment 7 Peter Platek 2014-12-18 09:30:22 EST

You are correct and I just double checked as well.  The same behaviour happens in eclipse jee without Code Recommenders installed.  I guess this bug should be moved to JDT.

Comment 8 Marcel Bruch 2014-12-18 10:09:55 EST

Hey committers, is this something your AST parser can recover from (I guess it wouldn't be easy)? It's a (small) surprise that completion works when the next type is a primitive like int but will fail with a type name, but you know your internals better.

Comment 9 Noopur Gupta 2014-12-18 12:27:51 EST

(In reply to Marcel Bruch from comment #8)
> Hey committers, is this something your AST parser can recover from (I guess
> it wouldn't be easy)? It's a (small) surprise that completion works when the
> next type is a primitive like int but will fail with a type name, but you
> know your internals better.

Moving to JDT Core for analysis.

Comment 10 Markus Keller 2014-12-18 13:21:01 EST

(In reply to Marcel Bruch from comment #8)
> Hey committers, is this something your AST parser can recover from (I guess
> it wouldn't be easy)?

Yeah, I fear your guess is correct. The AST parser actually does recover

    ss String something;

... but not as we would expect. It assumes this is a variable declaration and recommends removing "something". The parser neither knows about line breaks nor about the upper/lowercase conventions for types and names.

> It's a (small) surprise that completion works when the
> next type is a primitive like int but will fail with a type name, but you
> know your internals better.

If you replace "String" by "int", then that token can't be a variable name any more, and the recovery goes a more favorable path.


A workaround is to add a ";" after the collection name, e.g.:

    void s(List<String> ss){
        ss;  // <- semicolon forces the compiler to recover "ss" separately
        String something;
    }

Comment 11 Eclipse Genie 2020-01-21 13:50:28 EST

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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.