recognize if(__ctfe) blocks

[WalterBright]

This is a partial solution to https://issues.dlang.org/show_bug.cgi?id=18472

It turns out to be necessary to properly recognize if (__ctfe) code blocks because different semantics apply. That's what this PR does. It takes advantage of it by:

1. allowing GC code in @nogc functions
2. preventing goto from entering a ctfe block

Todo in a followup: deal with unnecessary generation of TypeInfo's in betterC.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14913"

[WalterBright]

This is ready to go.

[ibuclaw]

Todo in a followup: deal with unnecessary generation of TypeInfo's in betterC.

This needs to be elaborated as to how it will be done, preferably with the change in question ready in another PR so we get the context rather than a piecemeal of the design.

As it currently stands, this and #14830 will just be reverted in 2 days.

[WalterBright]

#14830 solves the problem of calls to new and TypeInfo having code being generated for them, despite being it __ctfe blocks. It's the equivalent solution ldc and gdc use. It solves an actual bug, is simple, and causes no known problems. It would a shame to revert it.

This PR resolves the issue of being able to call the GC in a __ctfe block despite the function being @nogc or -betterC. It works and none of the other attempts at it work. It also prevents the suppression of emitting code for functions in betterC code that only calls the GC inside a __ctfe block.

The next PR relies on this one, and extends it to prevent the generation of TypeInfo from code within a __ctfe block. It both requires this PR, and is not any sort of conceptual leap over it.

[thewilsonator]

It would a shame to revert it.

It caused a regression, what else do you expect to happen?

[WalterBright]

what else do you expect to happen?

Merge the fix #14916

[ibuclaw]

preventing goto from entering a ctfe block

So now if (__ctfe) becomes a barrier to code? This seems like a bit of a nasty restriction to have.

[dkorpel]

This seems like a bit of a nasty restriction to have.

Why? if (__ctfe) is used to provide a separate path to work around limitations of CTFE, so functions such as dup and idup work at compile time. It's not pretty, but it's what we have. Do you know a situation where you want to jump from the runtime path into the ctfe path with goto?

[ibuclaw]

This seems like a bit of a nasty restriction to have.

Why? if (__ctfe) is used to provide a separate path to work around limitations of CTFE, so functions such as dup and idup work at compile time. It's not pretty, but it's what we have. Do you know a situation where you want to jump from the runtime path into the ctfe path with goto?

I can't think of a good analogy, but it's not about the use of the rule, rather the growing list of exceptions that must be remembered for that rule.

One alternative to consider, what about assert(__ctfe) being the barrier?

[WalterBright]

rather the growing list of exceptions that must be remembered for that rule.

The logic that goto cannot jump into a ctfe block is the same as that used to prevent jumping into a try block, scope block, and jumping past declarations.

what about assert(__ctfe) being the barrier?

Since existing code already uses if(__ctfe), they won't have to rewrite anything.

[dkorpel]

One alternative to consider, what about assert(__ctfe) being the barrier?

That would also be an exception to remember. if (__ctfe) assert(__ctfe) looks like a redundant assert that can be removed. The assert can also still be skipped over with goto.