pragma(__ctfe) (page 2)

On Thursday, 28 September 2023 at 06:02:05 UTC, Richard (Rikki) Andrew Cattermole wrote: > On 28/09/2023 5:58 PM, Bruce Carneal wrote: >> The assert hack is useful but limited. It will not fail at compile time, will not prevent all code/symbol generation, will not enable compile time understanding that the function is restricted to use at compile time (if that's useful apart from the other ...). > > This proposal (should this PR changed to it) would restrict that function to CTFE only. Correct.

On Thursday, 28 September 2023 at 06:04:51 UTC, Richard (Rikki) Andrew Cattermole wrote: > On 28/09/2023 6:04 PM, ryuukk_ wrote: >> Why couldn't the compiler already guess this? >> >> To me a simple static analysis would be enough and better, or is it too slow? time saved not generating what's not used could offset time spent on the analysis? > > When you do multi-step builds (which are common), this would result in link failures. Since you don't have all the code, you can't do any analysis without failures being possible. It would make druntime and Phobos fail to link correctly with a giant list of missing symbols. Correct. If the function is intended to actually be ctfe only, as marked, and a reference somehow gets emitted to be linked against, then you will see a link time error.

void foo() @nogc { int[] buf; if (__ctfe) { buf = new int[10000]; } else { buf = (cast(int*)malloc(int.sizeof * 10000))[0 .. 10000]; } scope(exit) if(!__ctfe) free(buf.ptr); ... // use buf }

On 9/28/23 4:02 AM, Richard (Rikki) Andrew Cattermole wrote:

On 28/09/2023 8:36 PM, Nicholas Wilson wrote:

It will screw up .di generation, and make separate compilation more difficult.

No not really, think about the constraints of CTFE.

You can't elide a function body which is to be used from CTFE. Since you have to have the function body to CTFE it.

So where the annotation exists, doesn't matter too much.

I think what Nic means is if you have a function:

string genMixin(string param) {
   assert(__ctfe);
   return "int " ~ param ~ " = 5;";
}

Now, if that doesn't go into the binary, what happens with the di generated file?

string genMixin(string param);

oops, there's the function, but it can't be called for CTFE, and it doesn't exist in the object file.

Personally, I don't see the problem here. Don't use .di files generation for d files that contain those functions.

Or the compiler can detect it, and omit the function, but meh.

-Steve

On 29/09/2023 6:08 AM, Steven Schveighoffer wrote: > On 9/28/23 4:02 AM, Richard (Rikki) Andrew Cattermole wrote: >> On 28/09/2023 8:36 PM, Nicholas Wilson wrote: >>> It will screw up .di generation, and make separate compilation more difficult. >> >> No not really, think about the constraints of CTFE. >> >> You can't elide a function body which is to be used from CTFE. Since you have to have the function body to CTFE it. >> >> So where the annotation exists, doesn't matter too much. > > I think what Nic means is if you have a function: > > ```d > string genMixin(string param) { > assert(__ctfe); > return "int " ~ param ~ " = 5;"; > } > ``` > > Now, if that doesn't go into the binary, what happens with the di generated file? > > ```d > string genMixin(string param); > ``` > > oops, there's the function, but it can't be called for CTFE, *and* it doesn't exist in the object file. > > Personally, I don't see the problem here. Don't use .di files generation for d files that contain those functions. > > Or the compiler can detect it, and omit the function, but meh. > > -Steve Yeah, I got it. Don't elide the function body of a CTFE only function, or one called from it and it will work fine, which is what I said :)

September 28, 2023

Re: pragma(__ctfe)

Posted by Dave P.
in reply to Steven Schveighoffer

Permalink

Dave P.

Posted in reply to Steven Schveighoffer

Permalink

On Thursday, 28 September 2023 at 17:04:00 UTC, Steven Schveighoffer wrote:

On 9/27/23 11:30 PM, Nicholas Wilson wrote:

I have need of the ability to suppress the code generation of functions for using mixin generation functions with dcompute. Below is a link to a PR to implement that functionality.

https://github.com/dlang/dmd/pull/15636

What are peoples thoughts on this?

Have you tried immediately-called lambdas?

What I need is for this to work:

void foo() @nogc
{
   int[] buf;
   if (__ctfe) {
      buf = new int[10000];
   }
   else {
      buf = (cast(int*)malloc(int.sizeof * 10000))[0 .. 10000];
   }
   scope(exit) if(!__ctfe) free(buf.ptr);
   ... // use buf
}

We need the compiler to back-off when it comes to enforcing runtime attributes in compile-time-only blocks. Without it, reasonable backup plans don't exist for what seems like obvious allowances. BetterC CTFE code becomes impossible, etc.

I'd also like to see assert(__ctfe) just suppress code generation, as mentioned.

-Steve

As far as I can tell, this already works.

import core.stdc.stdlib;
import core.stdc.stdio;
int foo() @nogc
{
   int[] buf;
   if (__ctfe) {
      buf = new int[10000];
   }
   else {
      buf = (cast(int*)malloc(int.sizeof * 10000))[0 .. 10000];
   }
   scope(exit) if(!__ctfe) free(buf.ptr);
   foreach(ref b; buf){
       b = 2;
   }
   int x = 0;
   foreach(b; buf){
       x += b;
   }
   return x;
}

enum z = foo();
pragma(msg, z);


void d_main(){
    int y = foo();
    printf("%d\n", y);
    printf("%d\n", z);
}

version(D_BetterC){
    extern(C)
    int main(){
        d_main();
        return 0;
    }
}
else {
    void main(){
        d_main();
    }
}

works with betterC, normal D, works at compile time, runtime.

It works as this bug was resolved: https://issues.dlang.org/show_bug.cgi?id=21492

On Thursday, 28 September 2023 at 11:05:07 UTC, Bruce Carneal wrote: > Correct. If the function is intended to actually be ctfe only, as marked, and a reference somehow gets emitted to be linked against, then you will see a link time error. Yes but that should be trivial to add a check during CallExp sema to emit a proper error message. There's a "are we in CTFE" flag in DMD `Scope`.

Forums