D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 16481 - invalid code accepted leading to linker error
Summary: invalid code accepted leading to linker error
Status: RESOLVED DUPLICATE of issue 15459
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P1 major
Assignee: No Owner
URL:
Keywords: accepts-invalid
Depends on:
Blocks:
 
Reported: 2016-09-09 13:40 UTC by John Colvin
Modified: 2022-11-10 14:24 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description John Colvin 2016-09-09 13:40:47 UTC
% cat mod.d
void blah()
{
    import std.algorithm;
    import std.conv;
    int[][] a;
    a.map!(x => x.map!to);
}
% dmd mod.d
Undefined symbols for architecture x86_64:
  "_D3std9algorithm9iteration32__T9MapResultS123std4conv2toTAiZ9MapResult6__ctorMFNaNbNcNiNfAiZS3std9algorithm9iteration32__T9MapResultS123std4conv2toTAiZ9MapResult", referenced from:
      _D3std9algorithm9iteration23__T3mapS123std4conv2toZ11__T3mapTAiZ3mapFNaNbNiNfAiZS3std9algorithm9iteration32__T9MapResultS123std4conv2toTAiZ9MapResult in mod.o
  "_main", referenced from:
     implicit entry/start for main executable
     (maybe you meant: __d_main_args, _D4core6thread6Thread7sm_mainC4core6thread6Thread )
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--- errorlevel 1


That code shouldn't compile (because of using std.conv.to without a target type), so it should never hit the linker at all.
Comment 1 John Colvin 2016-09-09 14:03:40 UTC
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.
Comment 2 ag0aep6g 2016-09-09 14:50:27 UTC
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
Comment 3 John Colvin 2020-12-14 13:58:31 UTC
(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)
Comment 4 RazvanN 2022-11-10 14:24:02 UTC

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