The compiler seems to inset an `assert(this !is null, "null this");` into my struct.
which is for all intents and purposes.
struct Foo {
    Bar b;
}

struct Bar {
    void* ptr;
}

I tried disabling the invariant but it complained that invariant requires a function body.
Is there a way to disable the implicit generations of invariants for my code other than -release? Like for a particular subset of files (separate invocations of the compiler is not an acceptable approach.

The reason being that I do not support global variables (of any kind) at the moment in dcompute and the insertion of the string literal to the assert breaks that.

On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
> The compiler seems to inset an `assert(this !is null, "null this");` into my struct.
> which is for all intents and purposes.
> struct Foo {
>     Bar b;
> }
>
> struct Bar {
>     void* ptr;
> }
>
> I tried disabling the invariant but it complained that invariant requires a function body.
> Is there a way to disable the implicit generations of invariants for my code other than -release? Like for a particular subset of files (separate invocations of the compiler is not an acceptable approach.
>
> The reason being that I do not support global variables (of any kind) at the moment in dcompute and the insertion of the string literal to the assert breaks that.

Looks like you'd need to do your own hack to disable this particular assert.
When it's used in a dcompute-context.

On Friday, 7 July 2017 at 08:24:22 UTC, Stefan Koch wrote:
> On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
>> [...]
>
> Looks like you'd need to do your own hack to disable this particular assert.
> When it's used in a dcompute-context.

Problem is it gets decided waaaay before.

On Friday, 7 July 2017 at 08:35:28 UTC, Nicholas Wilson wrote:
> On Friday, 7 July 2017 at 08:24:22 UTC, Stefan Koch wrote:
>> On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
>>> [...]
>>
>> Looks like you'd need to do your own hack to disable this particular assert.
>> When it's used in a dcompute-context.
>
> Problem is it gets decided waaaay before.

You should be able to hack around it.
LDC should be able to given you a hit when it hits this.
It's the first thing that gets put in the method.
So it has a fixed location.
Hence you can treat is it specially.

On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
> The compiler seems to inset an `assert(this !is null, "null this");` into my struct.
> which is for all intents and purposes.
> struct Foo {
>     Bar b;
> }
>
> struct Bar {
>     void* ptr;
> }
>
> I tried disabling the invariant but it complained that invariant requires a function body.
> Is there a way to disable the implicit generations of invariants for my code other than -release? Like for a particular subset of files (separate invocations of the compiler is not an acceptable approach.
>
> The reason being that I do not support global variables (of any kind) at the moment in dcompute and the insertion of the string literal to the assert breaks that.

Related: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md

On 7/7/17 4:21 AM, Nicholas Wilson wrote:
> The compiler seems to inset an `assert(this !is null, "null this");` into my struct.
> which is for all intents and purposes.
> struct Foo {
>      Bar b;
> }
> 
> struct Bar {
>      void* ptr;
> }

What? When is this invariant called? I've never heard of a hidden invariant being added to structs, structs are supposed to be free of such things.

I would call such a thing a bug.

-Steve

On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer wrote:
> On 7/7/17 4:21 AM, Nicholas Wilson wrote:
>> The compiler seems to inset an `assert(this !is null, "null this");` into my struct.
>> which is for all intents and purposes.
>> struct Foo {
>>      Bar b;
>> }
>> 
>> struct Bar {
>>      void* ptr;
>> }
>
> What? When is this invariant called? I've never heard of a hidden invariant being added to structs, structs are supposed to be free of such things.
>
> I would call such a thing a bug.
>
> -Steve

It was added because someone VIP demanded it I guess.
you can see the assert being added using -vcg-ast ;)

On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer wrote:
> On 7/7/17 4:21 AM, Nicholas Wilson wrote:
>> The compiler seems to inset an `assert(this !is null, "null this");` into my struct.
>> which is for all intents and purposes.
>> struct Foo {
>>      Bar b;
>> }
>> 
>> struct Bar {
>>      void* ptr;
>> }
>
> What? When is this invariant called? I've never heard of a hidden invariant being added to structs, structs are supposed to be free of such things.
>
> I would call such a thing a bug.
>
> -Steve

I am missing a couple of methods on Foo in that example that in turn call the invariant.
That at least can be disable with -release, which while certainly not desirable is not a blocker _for me at the moment_. It is certainly unacceptable in the long run to demand that if users wish to use DCompute that they can't have asserts _in the code running in the host_.

However at the moment I'm have more trouble with https://forum.dlang.org/thread/ayanaomqklqvknzrljid@forum.dlang.org any help appreciated.

On Friday, July 7, 2017 1:38:13 PM MDT Stefan Koch via Digitalmars-d wrote:
> On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer
>
> wrote:
> > On 7/7/17 4:21 AM, Nicholas Wilson wrote:
> >> The compiler seems to inset an `assert(this !is null, "null
> >> this");` into my struct.
> >> which is for all intents and purposes.
> >> struct Foo {
> >>
> >>      Bar b;
> >>
> >> }
> >>
> >> struct Bar {
> >>
> >>      void* ptr;
> >>
> >> }
> >
> > What? When is this invariant called? I've never heard of a hidden invariant being added to structs, structs are supposed to be free of such things.
> >
> > I would call such a thing a bug.
> >
> > -Steve
>
> It was added because someone VIP demanded it I guess.
> you can see the assert being added using -vcg-ast ;)

What does it even do? I don't see how it makes any sense for _anything_ to have an invariant if it's not explicitly declared. And honestly, I'm of the opinion that invariants with structs are borderline useless, because they're run even before opAssign, meaning that if you ever need to use = void; or use emplace, then you're screwed if you have an invariant, because it's bound to fail due to the object not having been initialized previously. Unfortunately, I couldn't get Walter to agree that it made sense to not call the invariant prior to opAssign being called - which is why SysTime no longer has an invariant (it was blowing up in people's code due to emplace IIRC). As such, it seems that much more stupid for structs to get any kind fo invariant automatically.

- Jonathan M Davis

On 7/7/17 9:38 AM, Stefan Koch wrote:
> On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer wrote:
>> On 7/7/17 4:21 AM, Nicholas Wilson wrote:
>>> The compiler seems to inset an `assert(this !is null, "null this");` into my struct.
>>> which is for all intents and purposes.
>>> struct Foo {
>>>      Bar b;
>>> }
>>>
>>> struct Bar {
>>>      void* ptr;
>>> }
>>
>> What? When is this invariant called? I've never heard of a hidden invariant being added to structs, structs are supposed to be free of such things.
>>
>> I would call such a thing a bug.
>>
> 
> It was added because someone VIP demanded it I guess.

Nope, it's really REALLY old (version 0.167):

https://github.com/dlang/dmd/commit/43a336d81c38817ae545becf02b7459836025c60

> you can see the assert being added using -vcg-ast ;)
> 

Hm... it doesn't look like an invariant, it just looks like an inserted assert inside every function.

An incorrect assert, IMO:

struct Foo
{
    int x;
    void foo() {}
}

void main()
{
   Foo *foo;
   foo.foo(); // shouldn't assert, wouldn't crash anyway.
}

And since when did we care about null pointers causing segfaults?

Can anyone vouch for this feature?

-Steve