Community
Participate
Working Groups
Build Identifier: just run into that, and my compiler didn't tell me: void function() { //... return; otherFunction(); // Code not reachable, my compiler didn't complain:-( } Reproducible: Always
fixed version to 7.0
I almost can do it now because I added Control Flow Graph - but it would be very buggy. Maybe can add very dumb one that checks for code after "return" statement only.
(In reply to comment #2) > I almost can do it now because I added Control Flow Graph - but it would be > very buggy. Maybe can add very dumb one that checks for code after "return" > statement only. No hurry necessary. I just think that the codan framework has all the potential to bring the CDT where the JDT already is: kind of have an intelligent compiler that provides the feedback very quick, and sometimes even provide quick fixes for it. Because of that, whenever I stumble over such useful error I will dump them to bugzilla. This way, whenever someone has the time to provide new checkers, having ideas about useful checkers shouldn't be a problem;-)
Created attachment 206903 [details] Checker to detect dead code I had a look at the Control Flow Graph Alena mentioned, and it looked quite useful. So I made a simple checkers that shows a warning if dead nodes are encountered in the graph. Currently, that's only after a return statement or the throwing of an exception. However, it looks like the ControlFlowGraphBuilder could just as well support more complicated dead code detection.
Hello Mathias. Have you tested the checker on big files? How is the performance?
Please make sure that the new checker is disabled by default. We can enable it later when we determine that it doesn't produce false positives.
Can you make multi-project eclipse patch? I cannot apply this one...
A dead code checker would be really welcome, but I think the control flow graph lacks a basic feature in order to implement something like that: evaluation of constant expression. AFAIK the control flow grraph creates decision nodes with outgoing edges regardless the condition. Example: int i = 0; if (i < 0) return 1; <--dead code return 2; OR int i = 0; while(1) { i++; } return 2; <----dead code Maybe we should open a new bug report to add a checker for "always true/false" conditions and set this as "blocked by". Without this feature the current patch is quite limited and I don't know if it's ok to add it.
(In reply to Marco Stornelli from comment #8) > A dead code checker would be really welcome, but I think the control flow > graph lacks a basic feature in order to implement something like that: > evaluation of constant expression. The control flow graph should already be able to do this: see ControlFlowGraphBuilder.isConstant().
(In reply to Nathan Ridge from comment #9) > (In reply to Marco Stornelli from comment #8) > > A dead code checker would be really welcome, but I think the control flow > > graph lacks a basic feature in order to implement something like that: > > evaluation of constant expression. > > The control flow graph should already be able to do this: see > ControlFlowGraphBuilder.isConstant(). Not exactly, it just checks for constant values instead of constant expression and only for if/else. It doesn't work with the examples I did.
(In reply to Marco Stornelli from comment #10) > Not exactly, it just checks for constant values instead of constant > expression The function used in the implementation of isConstant(), ValueFactory.getConstantNumericalValue(IASTExpression), should be able to take an arbitrary expression and, if it's a constant expression, give you its value. > and only for if/else. Sure, it may require additional hookup to use this facility for other types of control flow constructs. > It doesn't work with the examples I did. Note that in your first example, "i" is not a constant. For your first example to work as written (without adding "const" or "constexpr" to "i"), we would also need data flow analysis to determine that the value of "i" does not change between its declaration and its use in the if condition. That's a lot of more complexity in the general case, so I wouldn't bother with that for now.
(In reply to Nathan Ridge from comment #11) > (In reply to Marco Stornelli from comment #10) > > Not exactly, it just checks for constant values instead of constant > > expression > > The function used in the implementation of isConstant(), > ValueFactory.getConstantNumericalValue(IASTExpression), should be able to > take an arbitrary expression and, if it's a constant expression, give you > its value. > > > and only for if/else. > > Sure, it may require additional hookup to use this facility for other types > of control flow constructs. > > > It doesn't work with the examples I did. > > Note that in your first example, "i" is not a constant. For your first > example to work as written (without adding "const" or "constexpr" to "i"), > we would also need data flow analysis to determine that the value of "i" > does not change between its declaration and its use in the if condition. > That's a lot of more complexity in the general case, so I wouldn't bother > with that for now. Sorry for the confusion but it's what I meant with "constant expression". An expression with a value which don't change between declaration and condition as you said. So if I understood you will be ok with the current patch about dead code (maybe with the addition of current constant check for while/do-while and so on). I can take a look.
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
