Thread overview
[Issue 16481] invalid code accepted leading to linker error
Sep 09, 2016
John Colvin
Sep 09, 2016
John Colvin
Sep 09, 2016
ag0aep6g@gmail.com
Dec 14, 2020
John Colvin
Nov 10, 2022
RazvanN
September 09, 2016
https://issues.dlang.org/show_bug.cgi?id=16481

John Colvin <john.loughran.colvin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|invalid code accepted       |invalid code accepted
                   |leading to                  |leading to linker error

--
September 09, 2016
https://issues.dlang.org/show_bug.cgi?id=16481

--- Comment #1 from John Colvin <john.loughran.colvin@gmail.com> ---
Reduced version without phobos imports:

void blah()
{
    int[] a;
    a.map!(x => x.map!to);
}

template to()
{
}

template map(fun...)
{
    auto map(Range)(Range r)
    {
        alias RE = Range;
        alias _fun = unaryFun!fun;
        assert(!is(typeof(_fun(RE.init))));
        MapResult!(_fun, Range)(r);
    }
}

struct MapResult(alias fun, Range)
{
    alias R = Range;
    R _input;

    this(R)
    {
    }

    @property front()
    {
        fun(_input);
    }

}

template unaryFun(alias fun)
{
    alias unaryFun = fun;
}


Undefined symbols for architecture x86_64:

"_D3mod26__T9MapResultS73mod2toTAiZ9MapResult6__ctorMFNaNbNcNiNfAiZS3mod26__T9MapResultS73mod2toTAiZ9MapResult",
referenced from:
      _D3mod17__T3mapS73mod2toZ11__T3mapTAiZ3mapFNaNbNiNfAiZv in mod.o


If you comment out the assert then you get this error instead:

mod.d(34): Error: template mod.to cannot deduce function from argument types
!()(int[]), candidates are:
mod.d(8):        mod.to()
mod.d(19): Error: template instance mod.MapResult!(to, int[]) error
instantiating
mod.d(5):        instantiated from here: map!(int[])
mod.d(34):        instantiated from here: __lambda1!(int[])
mod.d(19):        instantiated from here: MapResult!(__lambda1, int[])
mod.d(5):        instantiated from here: map!(int[])

which is what I expect and looks ok.

--
September 09, 2016
https://issues.dlang.org/show_bug.cgi?id=16481

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid
                 CC|                            |ag0aep6g@gmail.com

--- Comment #2 from ag0aep6g@gmail.com ---
Reduced further:

----
enum e = is(typeof(fun!()));
void fun()() { auto m = MapResult!()(0); }
alias f = fun!();

struct MapResult()
{
    this(int) {}
    void front() { undefined(); }
}
----

Looks similar to issue 16239.

When the 0 in `MapResult!()(0)` is removed, the program compiles and links
(with -main). => accepts-invalid

--
December 14, 2020
https://issues.dlang.org/show_bug.cgi?id=16481

--- Comment #3 from John Colvin <john.loughran.colvin@gmail.com> ---
(In reply to ag0aep6g from comment #2)
> Reduced further:
> 
> ----
> enum e = is(typeof(fun!()));
> void fun()() { auto m = MapResult!()(0); }
> alias f = fun!();
> 
> struct MapResult()
> {
>     this(int) {}
>     void front() { undefined(); }
> }
> ----
> 
> Looks similar to issue 16239.
> 
> When the 0 in `MapResult!()(0)` is removed, the program compiles and links
> (with -main). => accepts-invalid

A little further info:

if you remove the enum e line, then compilation fails as expected, complaining about undefined.

If you change alias f = fun!() to void bar() { fun!(); } then there is no
change (confirming that it's not a question of whether the unused fun
instantiation needs to be emitted)

--
November 10, 2022
https://issues.dlang.org/show_bug.cgi?id=16481

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |razvan.nitu1305@gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---


*** This issue has been marked as a duplicate of issue 15459 ***

--