On Wednesday, 28 October 2015 at 10:02:01 UTC, Daniel Murphy
wrote:
If it's unreachable or not depends on what the template is
instantiated with, there is no clear concept of unreachable
code without knowing the template parameters.
If a statement in a template is reachable in at least one
possible instantiation of that template, it is not "unreachable".
What is unclear about this as a concept?
Just because implementing this definition perfectly in the
compiler is difficult, doesn't mean the concept is unclear.
bool func(T)(T value) if (isUnsigned!T)
{
if (value < 0)
return true;
return false;
}
Here the first return is definitely dead code for any
instantiation, but to know this the compiler would have to
reverse-engineer properties from the template constraints,
which is not generally possible.
Detection of all dead code will never be "generally possible",
with or without templates involved - if it was you could
trivially solve the halting problem.
If false negatives are unacceptable, then we should remove the
warning entirely, as achieving that goal is mathematically
impossible on a normal computer.
[snip]
As one of the core compiler devs, I'm saying it sounds
infeasible. I don't think either of your suggested solutions
are implementable. Templates just do not work that way.
> 1. Defer "not reachable" warnings until compilation has been
> completed, and only issue the warning if *all* instantiations
of the
> statement were unreachable.
The exact set of instantiations depends on the current module
being compiled, so module A can still get an unreachable code
warning even if in an instantiation from module B the code is
reachable.
I know that solution #1 is far from perfect - it would, however,
significantly reduce the frequency of false positives. As I said
above, perfection is not the goal, since it is not even
theoretically possible due to the halting problem.
> 2. For semantic analysis purposes, first instantiate each
template
> using dummy parameters with the widest possible VRP ranges.
Only
> statements found to be "not reachable" in this dummy run
should
> actually generate warnings.
Will not work with compile-time introspection.
I'm not sure precisely what you're referring to here. I know
solution #2 would be a royal pain to implement, though, even if
it is possible.
In some trivial cases code can be found to be unreachable
without doing semantic analysis, and therefore can be done
before template instantiation. Being limited, I doubt this is
of much value.
Perhaps the warning should just be removed then.
