This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 550672 - Enhanced for each loop conversion creates wrong compilable code since 4.13M3
Summary: Enhanced for each loop conversion creates wrong compilable code since 4.13M3
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.13   Edit
Hardware: All All
: P3 blocker (vote)
Target Milestone: 4.13 RC2   Edit
Assignee: Jeff Johnston CLA
QA Contact: Jeff Johnston CLA
URL:
Whiteboard:
Keywords:
Depends on: 548002
Blocks:
  Show dependency tree
 
Reported: 2019-09-03 01:22 EDT by Michael Keppler CLA
Modified: 2019-09-04 21:33 EDT (History)
8 users (show)

See Also:
akurtakov: pmc_approved+
Lars.Vogel: pmc_approved+
noopur_gupta: review+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Keppler CLA 2019-09-03 01:22:23 EDT 
Bug 548002 added enhanced for each conversion based on collection iteration. That change leads to wrong compilable code when using 4.13M3, since it does not check whether other collections are based on the loop index.

Reproduction example:
        List<File> a = new ArrayList<>();
        List<File> b = new ArrayList<>();
        for (int i = 0; i < a.size(); i++) {
            System.out.print(a.get(i) + " " + b.get(i));
        }

The "enhanced for loop conversion" quickfix is available on that loop, although it iterates 2 collections and converts this to the completely wrong, but compilable

        List<File> a = new ArrayList<>();
        List<File> b = new ArrayList<>(); 
        for (File element : a) {
            System.out.print(element + " " + element);
        }

I set this to blocking, since "convert to enhanced for loop" is also a save action, that exists since a long time. So it may be enabled for many long time users (like myself), and suddenly produces wrong compilable code on saving files, without further notice to the user.
Comment 1 Noopur Gupta CLA 2019-09-03 11:50:08 EDT 
For 4.13, the changes in bug 548002 will be reverted.
Comment 2 Alexander Kurtakov CLA 2019-09-03 12:00:24 EDT 
Noopur, if this bug is straightforward to fix wouldn't it be simpler to fix it?
Comment 3 Noopur Gupta CLA 2019-09-03 12:09:33 EDT 
(In reply to Alexander Kurtakov from comment #2)
> Noopur, if this bug is straightforward to fix wouldn't it be simpler to fix
> it?
Yes, that would be fine. As discussed in bug 548002, I leave it to Jeff to also ensure that no such problems show up for 4.13 instead of reverting the feature.
Comment 4 Eclipse Genie CLA 2019-09-03 14:05:29 EDT 
New Gerrit change created: https://git.eclipse.org/r/148833
Comment 5 Jeff Johnston CLA 2019-09-03 15:30:32 EDT 
Noopur, I believe that the fix for this problem is straight-forward and have provided a patch including new tests.  If the PMC would rather have a reversion, then I will revert the feature.
Comment 6 Noopur Gupta CLA 2019-09-04 02:03:36 EDT 
While testing this fix, I came across another regression bug 550726.

Since this clean up is usually enabled as a save action in users' workspaces, these issues have a larger impact.

I am fine with not reverting the feature due to code complications but please revisit all the changes released for bug 548002 and make sure that the obvious issues are fixed in 4.13.
Comment 8 Eclipse Genie CLA 2019-09-04 11:13:58 EDT Comment hidden (obsolete)
Comment 9 Jeff Johnston CLA 2019-09-04 21:33:35 EDT 
Verified for 4.13RC2 using I20190904-1805 build