Community
Participate
Working Groups
Build Identifier: This includes fixes for creating a local variable, a parameter or a field. Reproducible: Always
Created attachment 173719 [details] CxxAstUtils updated Extended type inference in CxxAstUtils, used by fixes
Created attachment 173720 [details] Fixes QuickFixCreateField QuickFixCreateLocalVariable QuickFixCreateParameter
Hi Tomasz, I applied the latest patch from bug 309760 and the two patches from this bug, but getIndexFromMarker seems to be missing. Did I forget something?
Created attachment 174269 [details] updated AbstractCodanCMarkerResolution Actually I did forget something while splitting the previous (big) patch from bug 309760 into smaller ones. Here's the missing part.
Created attachment 174766 [details] Fixes More strict applicability test
*** cdt cvs genie on behalf of elaskavaia *** Bug 319196 - updated utils with more useful methods (contributed by Tomasz Wesolowski) [*] CxxAstUtils.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.core.cxx/src/org/eclipse/cdt/codan/core/cxx/CxxAstUtils.java?root=Tools_Project&r1=1.4&r2=1.5
For patch#2 updated AbstractCodanCMarkerResolution I did not add methods for getArtuments - they are specific to a problem not to quick fix. I modified code for quick fixed - extracted an abstract class to lock the index, also for next time please do not leave e.printStackTrace() in the code - replace with eclipse logging. Applied to trunk. Also added test you sent me by e-mail. For bugs in these and extra tests please open another bug.
*** cdt cvs genie on behalf of elaskavaia *** Bug 319196 updated to add common method [*] AbstractCodanCMarkerResolution.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.ui/src/org/eclipse/cdt/codan/ui/AbstractCodanCMarkerResolution.java?root=Tools_Project&r1=1.3&r2=1.4 [+] CreateLocalVariableQuickFixTest.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.core.test/src/org/eclipse/cdt/codan/internal/checkers/ui/quickfix/CreateLocalVariableQuickFixTest.java?root=Tools_Project&revision=1.1&view=markup [*] plugin.xml 1.8 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/plugin.xml?root=Tools_Project&r1=1.7&r2=1.8 [+] messages.properties http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/src/org/eclipse/cdt/codan/internal/checkers/ui/quickfix/messages.properties?root=Tools_Project&revision=1.1&view=markup [+] QuickFixCreateParameter.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/src/org/eclipse/cdt/codan/internal/checkers/ui/quickfix/QuickFixCreateParameter.java?root=Tools_Project&revision=1.1&view=markup [+] Messages.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/src/org/eclipse/cdt/codan/internal/checkers/ui/quickfix/Messages.java?root=Tools_Project&revision=1.1&view=markup [+] AbstractAstRewriteQuickFix.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/src/org/eclipse/cdt/codan/internal/checkers/ui/quickfix/AbstractAstRewriteQuickFix.java?root=Tools_Project&revision=1.1&view=markup [+] QuickFixCreateLocalVariable.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/src/org/eclipse/cdt/codan/internal/checkers/ui/quickfix/QuickFixCreateLocalVariable.java?root=Tools_Project&revision=1.1&view=markup [+] QuickFixCreateField.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/src/org/eclipse/cdt/codan/internal/checkers/ui/quickfix/QuickFixCreateField.java?root=Tools_Project&revision=1.1&view=markup [*] MANIFEST.MF 1.11 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/codan/org.eclipse.cdt.codan.checkers.ui/META-INF/MANIFEST.MF?root=Tools_Project&r1=1.10&r2=1.11
Hi, I tested the quick fix in a simple case: #include "TestClass.h" TestClass::TestClass() { foo(a, b); } void TestClass::foo(int a, int b) { } If I use create field on 'a' and 'b', their type is void instead of int. Should I open a bug for this? Or is this covered by a refactoring bug?
Yes please. I had this problem too. Void as a default does not make any sense. void a; is semantical nonsense.
Void declarations are generated as the fallback when no type can be inferred. In this case the problem was caused by the fact that tryInferTypeFromFunctionCall failed because of astName.getTranslationUnit().getIndex() returning null. This happened only with "create field" fix, curiously. I solved the problem by passing the correct project-index to createDeclaration.
Created attachment 174907 [details] Additional fix for type inference
Created attachment 174908 [details] mylyn/context/zip
sorry for irrelevant second attachment
this bugs is resolved. please add you new patch to another bug. open one if not already exists. And should should fall back to "int" to "void" in any case.
Here is new bug 320575
