Comment #0 by timothee.cour2 — 2014-02-24T16:59:52Z
test.d:
module test;
public:
import std.string;
import std.algorithm;
main.d:
import test;
import std.string;
void main(){ auto a=" af ".strip;}
dmd -c -o- main.d
main.d(4): Error: test.strip at test.d conflicts with std.string.strip(C)(C[] str) if (isSomeChar!C) at phobos/std/string.d(1268)
Remove any of the 4 imports and it'll compile.
Also, there's no line number in 'at test.d'
Comment #1 by timothee.cour2 — 2014-02-24T17:01:08Z
actually this is a regression (worked in 2.063)
Comment #2 by dlang-bugzilla — 2014-02-24T20:53:55Z
This is not a compiler bug. It has nothing to do with 314.
The problem is that 'strip' is defined in both std.string and std.algorithm.
Comment #5 by dlang-bugzilla — 2014-03-23T01:33:53Z
This is a compiler bug because this program doesn't compile (as is expected):
/////// test.d //////
import std.algorithm;
void main()
{
" af ".strip;
}
/////////////////////
And this program compiles (as it should):
/////// test.d //////
import std.algorithm;
import std.string;
void main()
{
" af ".strip;
}
/////////////////////
Note that the above program differs from OP's only in how imports are "funneled".
Therefore, there should be no conflict, because out of std.algorithm.strip and std.string.strip, only one will work with those parameters.
Comment #6 by k.hara.pg — 2014-03-23T08:57:48Z
(In reply to comment #4)
> This is not a compiler bug. It has nothing to do with 314.
> The problem is that 'strip' is defined in both std.string and std.algorithm.
This is a compiler bug on cross-module overload set handling. It's not directly related to issue 313 & 314.
> test.d:
> module test;
> public:
> import std.string;
> import std.algorithm;
In test.d, 'strip' is a cross module overload set (CMOS) of 'std.string.strip' and 'std.algorithm.strip'.
> main.d:
> import test;
> import std.string;
> void main(){ auto a=" af ".strip;}
In main.d, 'strip' is a CMOS of the CMOS in test.d and 'std.stding.strip'.
So, the newly created CMOS should be merged to the set [std.string.strip, std.algorithm.strip]. But currently OverloadSet and template cannot be merged into one OverloadSet object in ScopeDsymbol::search.
Comment #7 by k.hara.pg — 2014-05-14T13:40:03Z
One more test case of this issue:
module test01;
private mixin template MixTmp(T, int x)
{
template foo(U) if (is(U == T))
{
enum foo = x;
}
}
mixin MixTmp!(int, 1);
mixin MixTmp!(long, 2);
------------
module test02;
private mixin template MixTmp(T, int x)
{
template foo(U) if (is(U == T))
{
enum foo = x;
}
}
mixin MixTmp!(float, 3);
mixin MixTmp!(real, 4);
------------
import test01, test02;
import std.stdio;
void main()
{
writeln( foo!int );
}
In module test01 and test02, 'foo' make individual overload sets. And in module test03, the imported two overload sets 'foo' should be merged to a new overload set 'foo' which contains four mixed-in templates.
Comment #8 by k.hara.pg — 2014-07-29T14:30:24Z
(In reply to Walter Bright from comment #4)
> This is not a compiler bug. It has nothing to do with 314.
>
> The problem is that 'strip' is defined in both std.string and std.algorithm.
But their signatures don't have ambiguity. With one string argument, " af ".strip == strip(" af ") should match only to std.string.strip. So this is a compiler bug.
Comment #9 by github-bugzilla — 2014-07-29T23:10:03Z
I don't like the term cross module overload set, because an overload sets is a set of overloads from different modules (or mixin templates) by definition.
The bug resolution to flatten all nested overload sets into a single overload set seems to be semantically correct.
Comment #13 by code — 2014-07-29T23:30:24Z
*** Issue 7327 has been marked as a duplicate of this issue. ***
Comment #14 by github-bugzilla — 2014-07-31T02:35:22Z