digitalmars.D.learn - delegate passed in annotation struct cannot be invoked.
- Alexandru Ermicioi (35/35) Dec 29 2016 Given code below:
- Stefan Koch (8/43) Dec 29 2016 It's a delegate and not function.
- Alexandru Ermicioi (6/12) Dec 29 2016 Yep, making it a function, will eliminate the problem.
- Stefan Koch (6/19) Dec 29 2016 ldc accepts invalid code there.
- Alexandru Ermicioi (5/9) Dec 30 2016 Nope, tried with dmd v2.071.2 and it gives same error as v2.072.1.
Given code below:
import std.stdio;
struct Annotation {
public int delegate(int) dg;
}
void main() {
import std.traits;
__traits(getAttributes, Cls)[0].dg(20).writeln;
}
Annotation(delegate int(int d) {
return d;
})
class Cls {
void method() {
}
}
Dmd will complain with following statement for the delegate
passed in annotation:
src/app.d(13,13): Error: delegate app.__dgliteral6 is a nested
function and cannot be accessed from D main.
GDC will just throw internal compiler exception:
src/app.d: In function ‘D main’:
src/app.d:20:2: internal compiler error: in get_frame_for_symbol,
at d/d-codegen.cc:3981
__traits(getAttributes, Cls)[0].dg(20).writeln;
^
LDC will not argue, and compile it flawlessly, and return 20 as
expected.
So the question, is the dmd error correct behavior?
If so, how the delegate is nested, and what is context that it is
nested in?
DMD version is: v2.072.1
LDC version is: v1.1.0 based on v2.071.2 and LLVM 3.8.1
GDC version is: 6.2.1 20161215
Dec 29 2016
On Thursday, 29 December 2016 at 20:55:43 UTC, Alexandru Ermicioi
wrote:
Given code below:
import std.stdio;
struct Annotation {
public int delegate(int) dg;
}
void main() {
import std.traits;
__traits(getAttributes, Cls)[0].dg(20).writeln;
}
Annotation(delegate int(int d) {
return d;
})
class Cls {
void method() {
}
}
Dmd will complain with following statement for the delegate
passed in annotation:
src/app.d(13,13): Error: delegate app.__dgliteral6 is a nested
function and cannot be accessed from D main.
GDC will just throw internal compiler exception:
src/app.d: In function ‘D main’:
src/app.d:20:2: internal compiler error: in
get_frame_for_symbol, at d/d-codegen.cc:3981
__traits(getAttributes, Cls)[0].dg(20).writeln;
^
LDC will not argue, and compile it flawlessly, and return 20 as
expected.
So the question, is the dmd error correct behavior?
If so, how the delegate is nested, and what is context that it
is nested in?
DMD version is: v2.072.1
LDC version is: v1.1.0 based on v2.071.2 and LLVM 3.8.1
GDC version is: 6.2.1 20161215
It's a delegate and not function.
Therefore it will get a frame-ptr regardless, without checking if
it is needed or not, or if there is a frame to point to.
Since there is no frame to point to you get the error.
At least this is my guess.
Make the delegate a function and the error should disappear.
Dec 29 2016
On Thursday, 29 December 2016 at 21:07:00 UTC, Stefan Koch wrote:It's a delegate and not function. Therefore it will get a frame-ptr regardless, without checking if it is needed or not, or if there is a frame to point to. Since there is no frame to point to you get the error. At least this is my guess. Make the delegate a function and the error should disappear.Yep, making it a function, will eliminate the problem. Though what I'm also curious is why on LDC it compiles and runs, while on DMD it does not? Should it be registered as a bug on issues.dlang.org, or at ldc bug tracker?
Dec 29 2016
On Thursday, 29 December 2016 at 21:19:18 UTC, Alexandru Ermicioi wrote:On Thursday, 29 December 2016 at 21:07:00 UTC, Stefan Koch wrote:ldc accepts invalid code there. But it might be that dmd 2.071.2 did that as well. If so It will be fixed as soon as ldc updates the front-end version.It's a delegate and not function. Therefore it will get a frame-ptr regardless, without checking if it is needed or not, or if there is a frame to point to. Since there is no frame to point to you get the error. At least this is my guess. Make the delegate a function and the error should disappear.Yep, making it a function, will eliminate the problem. Though what I'm also curious is why on LDC it compiles and runs, while on DMD it does not? Should it be registered as a bug on issues.dlang.org, or at ldc bug tracker?
Dec 29 2016
Alexandru Ermicioi <alexandru.ermicioi gmail.com> On Thursday, 29 December 2016 at 21:29:47 UTC, Stefan Koch wrote:ldc accepts invalid code there. But it might be that dmd 2.071.2 did that as well. If so It will be fixed as soon as ldc updates the front-end version.Nope, tried with dmd v2.071.2 and it gives same error as v2.072.1. I think I'll add a bug report to ldc, about not emitting the error. Thanks for help.
Dec 30 2016