[cfe-dev] -Wunreachable-code and templates

[Ted Kremenek]

On Dec 2, 2011, at 12:14 AM, David Blaikie wrote:

> Before doing that tidyup I decided to have a go at the "simple" thing
> - doing unreachable code on templates instead of their instantiations.
> No doubt it's not the tidiest implementation (suppressing all the
> other analysis based warnings when 'dependent' is true is a bit
> intrusive/repetitive) but it seems to show the concept fairly well.
> 
> I don't think we'd discussed in detail what problems might arise from
> this approach - certainly we know cases that we can't prove (such as a
> dependent function call which may or may not be noreturn) but
> non-dependent calls to noreturn functions, for example, seem to work
> correctly (without regressing your test cases that cover the dependent
> noreturn case).
> 
> Are there other cases I've missed where this approach could be problematic?

Hi David,

Thank you for being persistent.  :)

I think this approach is worth pursuing further only if there is an algorithmic justification that it is doing the right thing.  Since each instantiation of a template can have slightly different control-flow (mainly due to noreturn, but there may be other cases we haven't considered), we'd need to be able to say that the "control-flow" of the uninstantiated template represents some kind of superset of the possible control-flow when the template is instantiated (or at least a superset of the statements that are reachable).

If 'noreturn' is the only issue, then this may actually work.  The uninstantiated template may have 'noreturn' calls, but by definition those will appear in the instantiated template as well.  Ab instantiation may have additional 'noreturn' calls, but my understanding is that this will only cause more code to become unreachable in the particular instantiation.  Thus as far as 'noreturn' is concerned, the uninstantiated template represents a correct under-approximation of the unreachable code in all instantiation.  Is this logic sound?

If it is, my main concern then comes down to the following:

(1) Are there are other issues that we are not considering where the uninstantiated template doesn't faithfully provide an under approximation of the reachable code?

(2) If we decide this approach is viable, which uninstantiated templates do we analyze?  For performance reasons, I don't think we should analyze all the uninstantiated templates, as we may find ourselves repeatedly analyzing a huge portion of the Boost and the STL, etc.  My suggestion is that when we encounter an instantiation, we go and check if we have already analyzed the uninstantiated template for this warning, and if not, do the analysis.

(3) Somewhat tangential, we would want to analyze explicit template instantiations an their own, since they represent "concrete" functions that were provided, not instantiated ones.

(4) I don't know the if the CFGBuilder is going to work all that well on uninstantiated templates.  There may be bugs here, or other fundamental issues (which i don't know about).

(5) We wouldn't want to do this approach wholesale for all analyses.  I think it mainly makes sense for the reachable code warnings, e.g. -Wunreachable-code or warning if a function doesn't return.  Analyses like -Wuninitialized, etc., would want to keep working on instantiated templates since (a) they need the more precise semantics of the instantiated templates to work correctly and (b) it is okay if we flag a warning in one instantiation that doesn't appear in an other (since that is a genuine issue).

What do you think?

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111202/47316444/attachment.html>