Bug 23815 – closure allocated even if the escape is only used to access static members

Status
RESOLVED
Resolution
DUPLICATE
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2023-03-29T19:41:05Z
Last change time
2023-04-13T14:57:54Z
Keywords
performance
Assigned to
No Owner
Creator
Basile-z
See also
https://issues.dlang.org/show_bug.cgi?id=23835

Comments

Comment #0 by b2.temp — 2023-03-29T19:41:05Z
# Summary D allocates a closure for an escaped aggregate instance even if only used to access a static member. # Example ```d class C { static int i; } auto v(C c) { return {return c.i;}(); // it thinks `c` is escaped } ``` # IR output This is not a LDC bug but we can verify more easily that a closure is allocated using its IR output: https://godbolt.org/z/j3EvorjzY. Note that it is not a dup of 17804. Here the escape is well on the stack, it is really that there should not be any escape.
Comment #1 by salihdb — 2023-03-29T21:42:28Z
No problem, the code compiles for me: alias T = int; class C {  static T i;  this(T n) { i = n; } } alias fo = T function(); // not compile alias foo = T delegate(); // compile auto ID(C c) {  foo f = () => c.i;  return f(); } void main() { auto test = new C(42);  assert(test.ID == 42); }
Comment #2 by b2.temp — 2023-03-29T22:51:35Z
> No problem, the code compiles for me: It's not a bug report, it's about the fact that the front-end add the code to allocate a closure that's useless. Then it is eventually optimized away but in first place it should not even be there, even without optimz.
Comment #3 by alphaglosined — 2023-04-13T14:57:54Z
Let's mark this one as a duplicate, as the other issue has an explanation from Razvan about why it doesn't work. *** This issue has been marked as a duplicate of issue 23835 ***