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