[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

Basile-z  changed:

   What|Removed |Added

 CC|b2.t...@gmx.com |

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

Basile-z  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Basile-z  ---
The bug as an ICE is gone now. Open another issue if the compilation is
supposed to succeed.

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

--- Comment #5 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #4)
> 
> This is how you track the 'this' pointer for mmap to the frame of
> printstuffs.
> 

Also note that you can't trust toParent2() here, as it returns the function the
template was declared in. Parent access should be done through toParent() to
properly inspect whether a template comes from another template instance
(declared in another context).

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

--- Comment #4 from Iain Buclaw  ---
Note to anyone looking.

For function call to mmap(...).


Given that:

FuncDeclaration fd = void mmap(T...);

fd.toParent2() == main();
fd.parent.isTemplateInstance() == template mmap(T...);
fd.parent.isTemplateInstance().tinst == template printstuffs(T...);
fd.parent.isTemplateInstance().tinst.toAlias() == void printstuffs(T...);

This is how you track the 'this' pointer for mmap to the frame of printstuffs.

Fix for gdc will happen soon.  Someone will have to look at dmd.

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

--- Comment #3 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #2)
> 
> The front-end should ideally have a way to notify the code generator of this
> somehow, to notify us that there's no need to check whether the call is
> legal.

You would, however, run into other problems if 'printer' actually modifies
anything in the parent frame.

void printstuffs(T...)(T args) {
int count = 0;
void printer(G)(G arg) {
writeln(arg);
count++;
}

mmap!printer(args);
}


In the above case, runtime would segfault.  As we have no way of determining
the context pointer IIUC.

The current AST handed from the front-end may be broken in this regard.

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #2 from Iain Buclaw  ---
The compiler is checking if the nested function 'printer' is reachable from the
function 'mmap'.

It's not, because 'printer' is nested inside 'printstuffs', as so is not
reachable.

This would fall under a category of functions that are called by alias ('fun'
is an alias to the function to call, of which the actual function is
unreachable from the scope of 'mmap').

The front-end should ideally have a way to notify the code generator of this
somehow, to notify us that there's no need to check whether the call is legal.

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

--- Comment #1 from elro...@protonmail.ch ---
Potentially relevant: dmd just segfaults, but gdc actually prints a message:

test.d: In function ‘mmap’:
test.d:7:8: internal compiler error: in get_frame_for_symbol, at
d/d-codegen.cc:2208
 fun(item);
^

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17836

b2.t...@gmx.com changed:

   What|Removed |Added

   Keywords||ice, ice-on-invalid-code
 CC||b2.t...@gmx.com

--