Fixing spurious "statement is not reachable" in template code

tsbockman via Digitalmars-d digitalmars-d at puremagic.com
Tue Oct 27 09:04:18 PDT 2015


On Tuesday, 27 October 2015 at 12:28:38 UTC, Steven Schveighoffer 
wrote:
> On 10/26/15 1:08 PM, tsbockman wrote:
>> My solution #2 is the same as the one you proposed - the dummy 
>> parameter
>> stuff is my vague proposal for a way to actual implement this 
>> behavior
>> in the compiler.
>>
>> The halting problem is no more of an issue than it is for the 
>> compiler
>> today. (That is to say, the halting problem leads to false 
>> negatives,
>> but not false positives.)
>
> OK, as long as the default behavior isn't to reject the code, I 
> suppose this is simply an optimization.

Right.

> But the problem I see is that only static ifs that reduce to 
> static if(true) would be considered to cause a short-circuit 
> (e.g. someint <= int.max). Unless the compiler can VRP 
> according to the template constraint, which may be possible in 
> simple circumstances, but not in all circumstances.

I think the next piece of Lionello Lunesu's PR which I am 
updating might actually do that; I'll have to check later. 
Regardless, you are correct solution #1 will substantially reduce 
the opportunities for constant folding.

> It just seems like it's an unnecessary layer. I think we should 
> start with the simple accept all code that branches based on 
> compile-time variables.

Can outline which specific code in the compiler you would modify 
to accomplish this?

Because at the moment, having looked at the relevant front end 
code, I don't see a way that is meaningfully simpler than my 
dummy parameter idea.

>> The reason solution #2 could end up being a ton of work, is 
>> that a dummy
>> type will have to be created to apply this solution to cases 
>> like:
>>
>> module main;
>>
>> import std.stdio;
>>
>> void reachIf(T...)()
>> {
>>      if(T.length != 1 || T[0].sizeof != 4)
>>          return;
>>      writeln("reached"); // Warning: statement is not reachable
>> }
>
> Inherent properties of types that can be variable could be 
> considered variables just like any other size_t or int. 
> Therefore, branching based on that would fall under the same 
> issue.
>
> I think the "ton of work" is avoidable.

I have only a fuzzy understanding of the compiler's code right 
now, but it seems to me that the way it is currently structured 
does not readily allow for simultaneously making information 
available to `static if` and CTFE, while also hiding it from dead 
code detection.

I get what you want, but if it's simple to actually make the 
compiler do it, I don't see how yet. If you do, please give me 
the names of some files or functions to study in the front end.


More information about the Digitalmars-d mailing list