Community
Participate
Working Groups
Consider a few examples first: struct My { int value; // Case 1: getValue() should be constant cause it does not write class members void getValue() { return value }; // Case 2: increment() should be static cause it does not use class members. int increment(int _value) { return _value+1; } // Case 3: Class member 'value' cannot be changed in constant method getNewValue(). int getNewValue() const { return ++value; } // Case 4: Static method decrement() cannot access class member 'value'. static void decrement() { return --value; } }; So checker reports a problem on the next cases: 1. class method should be constant (there is no writing to the class members and calls of another non-constant methods); 2. class method should be static (there is no access to the class members); 3. class member is written in a constant method; 4. class member is accessed in a static method; NOTES: - There is no warning for virtual methods in cases 1 & 2 (cause their signature is derived from base classes and probably cannot be changed). - There is no check if non-constant method is called from constant one cause CDT Indexer does not resolve it correctly (and problem binding checker reports an error)
Created attachment 193586 [details] Basic checker implementation Can somebody review and commit or comment my patch?
(In reply to comment #1) It would be nice if the logic implemented in this checker was also applied to content assist. See http://bugs.eclipse.org/bugs/show_bug.cgi?id=263154#c3.
(In reply to comment #2) > It would be nice if the logic implemented in this checker was also applied to > content assist. See http://bugs.eclipse.org/bugs/show_bug.cgi?id=263154#c3. I think, CODAN warning (or error) will be quite enough. I want context assist to show class members cause if I made method static by mistake I want to finish it first and then fix its signature. However, I can think about moving checking functionality to CDT core utils. Is it necessary?
(In reply to comment #3) > However, I can think about moving checking functionality to CDT core utils. Is > it necessary? Yes, please.
Note that 3 and 4 are semantic error (i.e. would be caught by a compiler) and as such should be of diffrent category (done) and marker type (markerType=org.eclipse.cdt.codan.core.codanSemanticProblem), and well as run as you type only (not on full build because there is no point compete with compiler)
(In reply to comment #5) > Note that 3 and 4 are semantic error (i.e. would be caught by a compiler) and > as such should be of diffrent category (done) and marker type > (markerType=org.eclipse.cdt.codan.core.codanSemanticProblem), and well as run > as you type only (not on full build because there is no point compete with > compiler) Thanks, I fixed marker type, but I cannot understand how I should disable checker on full build. Can you help me?
> > Thanks, I fixed marker type, but I cannot understand how I should disable > checker on full build. Can you help me? @Override public void initPreferences(IProblemWorkingCopy problem) { super.initPreferences(problem); // these checkers should not run on full or incremental build getLaunchModePreference(problem).enableInLaunchModes(CheckerLaunchMode.RUN_AS_YOU_TYPE, CheckerLaunchMode.RUN_ON_DEMAND); }
(In reply to comment #7) > @Override > public void initPreferences(IProblemWorkingCopy problem) { > } Thanks!
Created attachment 194464 [details] Fixed checker implementation (see comment for details) Fixed: - fixed marker types; - run as you type only; - tests were added to integration suite.
New Gerrit change created: https://git.eclipse.org/r/139367
New Gerrit change created: https://git.eclipse.org/r/150293
Gerrit change https://git.eclipse.org/r/150293 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=a781cdf342c02cc507bd7754566eb4ce6c30cf62
