[cfe-dev] -Wunreachable-code and templates

[Ted Kremenek]

On Nov 30, 2011, at 9:48 AM, David Blaikie wrote:

>> The idea I had to tackle this was a bit simpler, although it could certainly be flawed.
> 
> One issue here based on the basic idea you've outlined: we still would
> be reporting on template instantiations, not the template itself. If
> there is unreachable code that's just unreachable in all
> instantiations of the template then we would actually report it once
> for each instantiation rather than just once (& a lesser issue: we
> wouldn't report it at all if there were no instantiations). Though
> this is less of a problem than the issue of false positives.

I thought about this issue more since I wrote my email late last night.  Your absolutely right that fundamentally we are still analyzing the instantiations.  Concerning the performance issues of analyzing multiple instantiations, or duplicate diagnostics, I think there are plenty of tricks we can play here to reduce that burden (e.g., unique diagnostics for this particular warning, which would be fairly cheap).

My concern, however, is that this approach is still fundamentally flawed.  By analyzing the instantiations, we are still impacted by the control-flow of that particular instantiation.  For example, suppose we have:

template <typename T> void foo() {
  {
    T x;
  }
  printf("is this dead?");
}

If the instantiated type for 'T' has a 'noreturn' destructor, then the printf() call is unreachable.  If it doesn't, it is reachable.

I still think my suggestion for having a CFG that retains some of the pruned edges is a good one, but the subtle dependencies from template instantiation on the semantics and the resulting control-flow is inherently complex and possibly too complicated to represent directly in the CFG.

Analyzing the template itself is also a non-starter.  Without instantiating a template, we really don't know what its control-flow semantics are.

Realistically, unless we really want to be super clever here, the most immediate solution to making -Wunreachable-code useful in the presence of templates is to simply have it skip templates entirely.  That will definitely lead to false negatives, but all of the false positives would be eliminated, which I think is far more important if we want this warning to be more actively used by users.  My concern about doing deadcode analysis on templates it is that it is very difficult for us to prove in the general case that a given template always has a snippet of code that is dead.  Certainly there are restricted cases where this is easy, but I think the common cases will not be trivial.  Deadcode analysis means that must prove, for *all* template instantiations, that the code is dead.  This is very different from analyses such as -Wuninitialized, which only need to look for a single example where a value is used uninitialized. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111130/381bc602/attachment.html>