[Issue 21044] [CTFE] Infinite loop in ForStatement::interpret
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Thu Sep 3 08:37:53 UTC 2020
https://issues.dlang.org/show_bug.cgi?id=21044
--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(In reply to Bruce Carneal from comment #2)
> (In reply to Iain Buclaw from comment #0)
> > Found on one iteration of mechanically reduced code (still dozens of files,
> > thousands of lines of code). Will copy it and reduce it further, but I
> > suspect that the final product will be code that looks like:
> >
> > ---
> > int foo()
> > {
> > for (;;) { }
> > return 0;
> > }
> >
> > static assert(foo() == 0);
> > ---
> >
> > If that is the case, then the compiler really should have proper detection
> > for this, to bail and error out if it finds a loop that never exits during
> > CTFE.
>
> As you noted during beerconf, dlang is Turing complete at compile time,
> which leaves us with the halting problem. (yes, indeed, we're working with
> power tools)
>
> Per Stefan's comments at beerconf the current approach to this includes a
> limit on recursion at compile time. From your experience, and anticipating
> recursion rewrites to iterative forms in the future, something more is
> needed.
>
> Is there some notion of "progress" at compile time that is readily
> available? A count of the source level symbols resolved perhaps? There's
> no "solving" the halting problem of course, just looking for a practical
> bound.
>
> Seems like current CTFE practice and implementation generate a number of
> intermediate structures that ultimately collapse to something roughly the
> size of the source input.
There's already some rudimentary code flow analysis in place. I can't imagine
it being too expensive to determine the likelihood of a branch returning. And
if the answer is never (infinite loop), then bail and error before executing
the code.
--
More information about the Digitalmars-d-bugs
mailing list