Fix issue 20603 - 'cannot use non-constant CTFE pointer in an initializer' in recursive structure with overlap

[dkorpel]

The function hasNonConstPointers was introduced in #102 (commit
14d37a1)

Despite the name, it notably seems to not take const/immutable into account. (Though I'm not sure transitive const already was a thing back in 2011).

This PR does not fix issue 11268 because this still fails:

struct A {uint d;}
immutable A abc = { 42 };
immutable(uint)* xyz = &abc.d;

However, instead of failing in initsem.d, it fails in todt.d where visitAddr(AddrExp e) only supports a StructLiteralExp, not a DotVarExp like above.
A DotVarExp could be supported in that function, but maybe the DotVarExp should be dissected at an earlier stage. I think arrays initializers work this way: all array elements are visited separately instead of the entire array, which is why the 'non-constant CTFE pointer' error was not raised when taking the address of an element.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20603	normal	'cannot use non-constant CTFE pointer in an initializer' in recursive structure with overlap

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#10882"

[RazvanN7]

@dkorpel Are you still pursuing this?

[dkorpel]

Yes. The thing that's blocking me is unfamiliarity with DMD's CTFE engine. There's an explicit test checking that "Pointers must not escape from CTFE" (see test/compilable/interpret3.d) and I'm changing that to only mutable pointers. It looks fine at first glance, but I'm a bit worried I'm overlooking something.

[RazvanN7]

I think that the issue is that the CTFE engine rewrites calls to the constructor without understanding that some fields are overlapping and doing so it ends up bypassing the call to the constructor. I looked into Issue 15938 which seems to be another manifestation of this fact.

This PR seems to fix the symptom but not the real cause of the issue.

[dkorpel]

This PR seems to fix the symptom but not the real cause of the issue.

Do you still think this PR is an improvement or should it be superseded? It's not just about the union code, the simplest manifestation is the first two lines of the test case:

enum immutable(int)* x = new int(3);
enum const(int)* y = new int(5);

Currently gives:

onlineapp.d(1): Error: cannot use non-constant CTFE pointer in an initializer `new int(3)`
onlineapp.d(2): Error: cannot use non-constant CTFE pointer in an initializer `new int(5)`

While the equivalent array case works.

enum immutable(int)[] a = new int[10];
enum const(int)[] b = new int[10];

[RazvanN7]

Why is this change required?

Nvm, I didn't see the traits(compiles) below.

[RazvanN7]

This change does make sense on its own. Seeing the union, I instantly thought about the other issue.