Fix Issue 16492 - support @nogc in debug{} blocks

[wilzbach]

debug already allows to use non-pure within pure scopes, imho it only makes sense to do the same for the rest.
If this gets approved, I am happy to do the same for @safe and nothrow.

Spec PR: dlang/dlang.org#2205

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	16492	enhancement	support @nogc in debug{} blocks

[TurkeyMan]

Oh thank god!

[WalterBright]

This can be merged with other compilable tests. Merging them makes the autotester run faster.

[WalterBright]

The code is good, but you're inventing another style of doing multiline conditionals.

if (e && e.op != TOK.error && f && sc.intypeof != 1 && !(sc.flags & SCOPE.ctfe) &&
    (f.type.ty == Tfunction &&
      (cast(TypeFunction)f.type).isnogc || (f.flags & FUNCFLAG.nogcInprocess) || global.params.vgc) &&
    !(sc.flags & SCOPE.debug_))

I.e. the dangling operator goes at the end, not the beginning, and subsequent lines should line up with the character after the opening (.

[WalterBright]

as already commented

[wilzbach]

This can be merged with other compilable tests. Merging them makes the autotester run faster.

I forgot to use ARGS_SETS. The test needs to be run at least once with -debug and once without.

[JinShil]

This feature leaves me feeling a little apprehensive. Is this truly in harmony with the intent of the debug statement, or are we looking to expedite a workaround to avoid the hard work of fixing some greater problem? Would this be an issue if our libraries and built-in types were less dependent on the GC? @andralex has hinted he and his staff are working on some revolutionary feature to be released soon™ that may remove reliance on the GC. Will that obsolete the need for this feature?

Note, I'm not against this, but I want to be sure there is deliberate intent behind it.

[timotheecour]

Wether it's debug or @!nogc or @gc we need an escape hatch at least for debugging. Trying to debug code inside @nogc @safe @nothrow is a pain otherwise.

[wilzbach]

There's a precendent:

As a concession to practicality, a pure function can also:
...
perform impure operations in statements that are in a ConditionalStatement controlled by a DebugCondition.

https://dlang.org/spec/function.html#pure-functions

debug shouldn't only be an escape hatch for pure, but for "turtles all the way down"

[marler8997]

I forgot to use ARGS_SETS. The test needs to be run at least once with -debug and once without.

Ah...looks like that new option comes in handy :)

[TurkeyMan]

@JinShil: writeln()

[dkgroot]

@wilzbach : '-debug' is a global compile flag, but @nogc / @pure are function local.

IMHO This could create some potentially unexpected results: Let's say you want to debug function X, so you switch on -debug, and now suddently function y.y.y.y (potentially in some library), suddenly could have (impure) side effects, require gc etc.
Switching on/off debugging should have as little as possible change in runtime, behaviour and hopefully no side effects.

[timotheecour]

This also worries me. Oftentimes you want just a local effect since you're just debugging one function.

Here's how nim does that:

https://nim-lang.org/docs/manual.html#pragmas-push-and-pop-pragmas

#here's an example with a particular compile option (`checks:off`) being locally applied
{.push checks: off.}
# compile this section without runtime checks as it is speed critical
# ... some code ...
{.pop.} # restore old settings

in D could look something like:

pragma(push, "-debug"); // could push other stuff eg "-noboundscheck, -O, -inline" etc
// compile this section with `-debug`
// ... some code ...
pragma(pop); // restore old settings

or perhaps more idiomatically, taking advantage of scoping rules of pragmas (3 types: single decl, all following decls, or inside {})

// could push other stuff eg "-noboundscheck, -O, -inline" etc
pragma(compilerOptions, "-debug"){
  // compile this section with `-debug`
  // ... some code ...
}
// old settings restored

[wilzbach]

This could create some potentially unexpected results:
suddenly could have (impure) side effect

This has been part of the DMD compiler and DSpec for years for pure! It's even in Andrei's TDPL.
No one complained, raised concerns or even opened a Bugzilla issue about it - the issues that were opened are that you can't use this feature to escape other attributes - it pops up every three to six minutes late months. A quick excerpt - the list is longer:

• https://issues.dlang.org/show_bug.cgi?id=18407
• https://forum.dlang.org/post/ojgxdtqodcamkqcrxgqc@forum.dlang.org
• https://forum.dlang.org/post/mailman.3228.1518060762.9493.digitalmars-d@puremagic.com
• https://forum.dlang.org/post/mailman.5.1473579980.2994.digitalmars-d@puremagic.com
• https://forum.dlang.org/post/wawqjpeesxxasfukbpwf@forum.dlang.org
• https://forum.dlang.org/post/eiifgqvoimbtkgcwfiiy@forum.dlang.org
  ...

debug already helps debugging, just not for all attributes.

[wilzbach]

in D could look something like:

This is already possible today. You can trick the compiler into thinking something is @nogc:

void assumeNogc(alias Func, T...)(T xs) @nogc {
	import std.traits;
	static auto assumeNogcPtr(T)(T f) if (
		isFunctionPointer!T || isDelegate!T
	) {
  	    enum attrs = functionAttributes!T | FunctionAttribute.nogc;
    	    return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) f;
	};
	assumeNogcPtr(&Func!T)(xs);
};

[dkgroot]

@timotheecour Do really like you potential solution, would allow for nicely localized debugging !
@wilzbach If it is the status quo, so be it.
Side effects are sometimes difficult to detect and doubly so, if they are caused by debugging. So it might take a while :-)

[TurkeyMan]

@dkgroot

Switching on/off debugging should have as little as possible change in runtime, behaviour and hopefully no side effects.

I tend to expect switching on/off debug have enormous impact on runtime (ie, enable/disable all non-shipping debugging infrastructure; high runtime cost), and likely have loads of 'side effects' (like emitting data to logs, telemetry, etc.)

Right now, it's impossible to debug pure/@nogc/etc code. This patch is necessary.

[dkgroot]

@TurkeyMan I meant negative/unpredictable side effects. When debugging your application, it would be nice if you could finetune your debug only to the part that you are actually interested in, ie the part you are trying to debug. That's why i did like @timotheecour solution so much.
Note: I am not against this PR at all, just wanted to raise a potential issue that should be considered before accepting it.

It has unique switches

[WalterBright]

I pulled this because this solution is simple. The casting solution is just too awful, and the push/pop is just annoying. When I write debug code, I don't care about correctness, I just need to do some logging or extra checking, and the compiler should relax its usual strict pedantic checking for it. If you ship code with debug on, well, that's your choice and your problem :-)

[JinShil]

Well, that addresses my concerns 😆

UPDATE: I think that comment could easily be misinterpreted. What I mean by the above comment is @WalterBright addressed my concerns completely and definitively in a single K-Pow! I was wondering about the intent behind debug {} and the inventor of the language made it abundantly clear.

[TurkeyMan]

Follow up for the other attributes expressing the same problem?

[wilzbach]

Yes, but they are more complicated.
In the mean time there's https://issues.dlang.org/show_bug.cgi?id=18407, s.t. this doesn't get lost.

[andralex]

@TurkeyMan what other attributes would be left?

cc @RazvanN7

[wilzbach]

@TurkeyMan what other attributes would be left?

nothrow and @safe

[WalterBright]

@JinShil thanks for the clarification. Think of debug like granting root privileges, or like attaching a symbolic debugger to the program. Debugging may need such access.

[JackStouffer]

Oh man, thank you for pulling this an working on the other attributes. This is my biggest pain point on D.

I've been doing this in my projects, and I'm looking forward to deleting this cruft

version (noAttributes)
{
    unittest
    {
        runTests();
    }
}
else
{
    @safe pure unittest
    {
        runTests();
    }
}

[PetarKirov]

@wilzbach awesome! Can you add a changelog and update the spec pls?

[wilzbach]

@wilzbach awesome! Can you add a changelog and

It technically already appears on the changelog, but I doubt anyone will notice:

I think it makes sense to wait with a proper changelog entry until nothrow and @safe are done too, because otherwise the question "why not @safe and nothrow" will immediately come up.

update the spec pls?

Spec is already updated. See dlang/dlang.org#2205 and dlang/dlang.org#2209

[PetarKirov]

Thanks Seb, I saw those PRs later than this one.