Bugzilla – Full Text Bug Listing
| Summary: | [quick assist] [extract method] Calling extract method from a selection | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Pascal Rapicault <pascal> |
| Component: | UI | Assignee: | Deepak Azad <deepakazad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | deepakazad, dirk_baeumer, frederic_fusier, markus.kell.r, reprogrammer |
| Version: | 3.0 | ||
| Target Milestone: | 3.8 M5 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| See Also: | https://git.eclipse.org/r/41302 | ||
| Whiteboard: | |||
| Bug Depends on: | 81784 | ||
| Bug Blocks: | |||
|
Description
Pascal Rapicault
The problem is that the scanner contains the newline characters (/n/r ....) in the length of the line comment. Moving to JDT/Core to comment on the rational to contain newline characters in line comments. In fact, new line is not in comment... this is current way to check it which is not correct. Scanner current position (got with #getCurrentScannerEndPosition()) after having parsed a line comment is set after new line characters. But, comment stored position does not include them (ie. ends at first line character '\r'). So, the only issue here is that you're missing a way to get this correct line comment end... Note that this happens also in 2.1.3 Back to JDT/UI. I will open a new bug against JDT/Core component and put this bug as dependent. Then, you'll have a track to modify CommentAnanlyser as soon as new API will be available... Thanks Frederic. I cannot reproduce using 3.3 RC4... Do you know how this issue was fixed without the new API on IScanner (see bug 81784)? (In reply to comment #0) > In 3.0M2 > If you select the following code (up to the very last character) and ask > for "extract method" you'll get an error dialog indication "Selection ends > inside a comment" > > foo();//a comment 'Refactor > Extract method' works with 3.8 M3. However, 'Extract to method' proposal is not offered with Ctrl+1. Fix to go in QuickAssistProcessor.getExtractMethodProposal(...). The "if (coveringNode instanceof Block)" statement looks wrong, it might be better to just create the refactoring and let it handle all the cases. I will investigate. (In reply to comment #6) > Fix to go in QuickAssistProcessor.getExtractMethodProposal(...). The "if > (coveringNode instanceof Block)" statement looks wrong, it might be better to > just create the refactoring and let it handle all the cases. The 'Extract to Method' quick assist was not offered most of the times when more than one statement was selected! Small bug in getIndex(..) method used by the if statement which I have fixed. The if statement by itself is a cheap test before we create the refactoring, hence I have left it as is. I have also added a few basic tests for the quick assist, there were none previously. Fixed in master - 1271a2793e6915e1202f090c69cab99b5943a19d |