>> This compiles for me without error. When it runs, I get a stack
>> overflow.
>> The reason looks clear - foo(Args) is recursively calling itself. I
>> don't
>> think it's a bug in dmd.
>>
>
> I retried above code using new beta on two environments.
>
> Mac OS X 10.6.8 causes segmentation fault, but
> Scientific Linux release 6.0 64bit works fine.
>
> Does D allow above code?

If I understand that correctly then the chosen overload differs. This prints "variadic" for me. Can you recheck this for other setups and file a bug.

IMHO this should be an ambiguous overload error.
-----
import std.stdio;

struct S
{
     void foo(V)(in V v)
     {
         writeln("non-variadic");
     }

     void foo(Args...)(auto ref const Args args)
     {
         writeln("variadic");
     }
}

void main()
{
     S s;
     s.foo(10);
}

Yes, this is ambiguous.

Andrei

On 2/10/12 12:05 PM, Martin Nowak wrote:
>>> This compiles for me without error. When it runs, I get a stack
>>> overflow.
>>> The reason looks clear - foo(Args) is recursively calling itself. I
>>> don't
>>> think it's a bug in dmd.
>>>
>>
>> I retried above code using new beta on two environments.
>>
>> Mac OS X 10.6.8 causes segmentation fault, but
>> Scientific Linux release 6.0 64bit works fine.
>>
>> Does D allow above code?
>
> If I understand that correctly then the chosen overload differs. This prints "variadic" for me. Can you recheck this for other setups and file a bug.
>
> IMHO this should be an ambiguous overload error.
> -----
> import std.stdio;
>
> struct S
> {
> void foo(V)(in V v)
> {
> writeln("non-variadic");
> }
>
> void foo(Args...)(auto ref const Args args)
> {
> writeln("variadic");
> }
> }
>
> void main()
> {
> S s;
> s.foo(10);
> }
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Friday, February 10, 2012 12:51:37 Andrei Alexandrescu wrote:
> Yes, this is ambiguous.

The compiler would give an error then. Fortunately, it's easy to make it work (just add a template constraint for Args.length > 1), but if a function call is ambiguous, then it shouldn't compile.

- Jonathan M Davis

On 2/10/2012 11:12 AM, Masahiro Nakagawa wrote:
> On Sat, Feb 11, 2012 at 3:49 AM, Walter Bright <walter at digitalmars.com <mailto:walter at digitalmars.com>> wrote:
>
>
>
>     On 2/10/2012 8:59 AM, Masahiro Nakagawa wrote:
>
>         Following code works on dmd 2.057, but causing segmentation fault on
>         dmd 2.058 beta.
>
>         -----
>         struct S
>         {
>            void foo(V)(in V v)
>            {
>            }
>
>            void foo(Args...)(auto ref const Args args)
>            {
>                foreach (i, T; Args)
>                    foo(args[i]);
>            }
>         }
>
>         void main()
>         {
>            S s;
>            s.foo(10);
>         }
>         ----
>
>         Does anyone report this issue?
>         This bug is critical for my msgpack-d and related libraries.
>
>
>     This compiles for me without error. When it runs, I get a stack overflow.
>     The reason looks clear - foo(Args) is recursively calling itself. I don't
>     think it's a bug in dmd.
>
>
> I retried above code using new beta on two environments.
>
> Mac OS X 10.6.8 causes segmentation fault, but
> Scientific Linux release 6.0 64bit works fine.
>
> Does D allow above code?

Do you mean the compiler seg faults or the compiled program seg faults?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120211/77945366/attachment.html>

On Sat, 11 Feb 2012 09:09:51 +0100, Walter Bright <walter at digitalmars.com> wrote:

>
>
> On 2/10/2012 11:12 AM, Masahiro Nakagawa wrote:
>> On Sat, Feb 11, 2012 at 3:49 AM, Walter Bright <walter at digitalmars.com <mailto:walter at digitalmars.com>> wrote:
>>
>>
>>
>>     On 2/10/2012 8:59 AM, Masahiro Nakagawa wrote:
>>
>>         Following code works on dmd 2.057, but causing segmentation
>> fault on
>>         dmd 2.058 beta.
>>
>>         -----
>>         struct S
>>         {
>>            void foo(V)(in V v)
>>            {
>>            }
>>
>>            void foo(Args...)(auto ref const Args args)
>>            {
>>                foreach (i, T; Args)
>>                    foo(args[i]);
>>            }
>>         }
>>
>>         void main()
>>         {
>>            S s;
>>            s.foo(10);
>>         }
>>         ----
>>
>>         Does anyone report this issue?
>>         This bug is critical for my msgpack-d and related libraries.
>>
>>
>>     This compiles for me without error. When it runs, I get a stack
>> overflow.
>>     The reason looks clear - foo(Args) is recursively calling itself. I
>> don't
>>     think it's a bug in dmd.
>>
>>
>> I retried above code using new beta on two environments.
>>
>> Mac OS X 10.6.8 causes segmentation fault, but
>> Scientific Linux release 6.0 64bit works fine.
>>
>> Does D allow above code?
>
> Do you mean the compiler seg faults or the compiled program seg faults?

/usr/bin/ld: Warning: size of symbol `_D3bug1S10__T3fooTiZ3fooMFxiZv'
changed from 64 in bug.o to 55 in bug.o
Both instantiations have the same mangling. The linkers seem to chose
different ones.

On 2/11/2012 1:11 AM, Martin Nowak wrote:
> On Sat, 11 Feb 2012 09:09:51 +0100, Walter Bright <walter at digitalmars.com> wrote:
>
>>
>>
>> On 2/10/2012 11:12 AM, Masahiro Nakagawa wrote:
>>> On Sat, Feb 11, 2012 at 3:49 AM, Walter Bright <walter at digitalmars.com <mailto:walter at digitalmars.com>> wrote:
>>>
>>>
>>>
>>>     On 2/10/2012 8:59 AM, Masahiro Nakagawa wrote:
>>>
>>>         Following code works on dmd 2.057, but causing segmentation fault on
>>>         dmd 2.058 beta.
>>>
>>>         -----
>>>         struct S
>>>         {
>>>            void foo(V)(in V v)
>>>            {
>>>            }
>>>
>>>            void foo(Args...)(auto ref const Args args)
>>>            {
>>>                foreach (i, T; Args)
>>>                    foo(args[i]);
>>>            }
>>>         }
>>>
>>>         void main()
>>>         {
>>>            S s;
>>>            s.foo(10);
>>>         }
>>>         ----
>>>
>>>         Does anyone report this issue?
>>>         This bug is critical for my msgpack-d and related libraries.
>>>
>>>
>>>     This compiles for me without error. When it runs, I get a stack overflow.
>>>     The reason looks clear - foo(Args) is recursively calling itself. I don't
>>>     think it's a bug in dmd.
>>>
>>>
>>> I retried above code using new beta on two environments.
>>>
>>> Mac OS X 10.6.8 causes segmentation fault, but
>>> Scientific Linux release 6.0 64bit works fine.
>>>
>>> Does D allow above code?
>>
>> Do you mean the compiler seg faults or the compiled program seg faults?
>
> /usr/bin/ld: Warning: size of symbol `_D3bug1S10__T3fooTiZ3fooMFxiZv' changed
> from 64 in bug.o to 55 in bug.o
> Both instantiations have the same mangling. The linkers seem to chose
> different ones.
>

I'm sorry, this is completely confusing.

1. Is the seg fault in dmd or the compiled program?

2. bug.o and then bug.o ??

// I.
void foo(V)(in V v)
{
}

// II.
void foo(Args...)(auto ref const Args args)
{
     foo(args[0]);
}

void main()
{
     foo(10);
}

-----

Deducing foo(10)
function arguments: rvalue int
I.  - MATCHconst
II. - MATCHexact

picks II

-----

Deducing foo(args[0])
function arguments: lvalue const(int)
I.  - MATCHexact
II. - MATCHexact

This is further disambiguated by leastAsSpecialized.
template.c(895):
         /* A non-variadic template is more specialized than a
          * variadic one.
          */
         if (isVariadic() && !td2->isVariadic())

picks I

-----

We end up instantiating both functions with the same argument types. Thus the mangling is the same and the linker will pick whatever he likes.

1. I think that variadic templates shouldn't be exact matches. 2. We shouldn't use tiebreakers but issue ambiguous errors.

A quick fix would be to change variadic templates to MATCHconvert as in
the attached patch.
But I think we should reduce the complexity of template matching rather
than patching it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-use-MATCHconvert-for-variadic-templates.patch
Type: application/octet-stream
Size: 1107 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120211/a51c013a/attachment.obj>

This is a lack of fixing bug 6208.
Now I'm creating a patch...

Kenji Hara
2012/02/11 19:58 "Martin Nowak" <dawg at dawgfoto.de>:

> // I.
> void foo(V)(in V v)
> {
> }
>
> // II.
> void foo(Args...)(auto ref const Args args)
> {
>    foo(args[0]);
> }
>
> void main()
> {
>    foo(10);
> }
>
> -----
>
> Deducing foo(10)
> function arguments: rvalue int
> I.  - MATCHconst
> II. - MATCHexact
>
> picks II
>
> -----
>
> Deducing foo(args[0])
> function arguments: lvalue const(int)
> I.  - MATCHexact
> II. - MATCHexact
>
> This is further disambiguated by leastAsSpecialized.
> template.c(895):
>        /* A non-variadic template is more specialized than a
>         * variadic one.
>         */
>        if (isVariadic() && !td2->isVariadic())
>
> picks I
>
> -----
>
> We end up instantiating both functions with the same argument types. Thus the mangling is the same and the linker will pick whatever he likes.
>
> 1. I think that variadic templates shouldn't be exact matches. 2. We shouldn't use tiebreakers but issue ambiguous errors.
>
> A quick fix would be to change variadic templates to MATCHconvert as in
> the attached patch.
> But I think we should reduce the complexity of template matching rather
> than patching it.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120211/861717d5/attachment-0001.html>

On Sat, 11 Feb 2012 12:05:24 +0100, kenji hara <k.hara.pg at gmail.com> wrote:

> This is a lack of fixing bug 6208.
> Now I'm creating a patch...
>
While this will solve the current problem, the following code will remain
broken.
The root cause is contradicting preferences for variadic templates
in deduceFunctionTemplateMatch and leastAsSpecialized.

void foo(V)(in V v)
{
}

void foo(Args...)(auto ref const Args args)
{
     foo(cast(const(int))args[0]);
}

void main()
{
     foo(10);
}

On Sat, Feb 11, 2012 at 5:09 PM, Walter Bright <walter at digitalmars.com>wrote:

> **
>
>
> On 2/10/2012 11:12 AM, Masahiro Nakagawa wrote:
>
> On Sat, Feb 11, 2012 at 3:49 AM, Walter Bright <walter at digitalmars.com>wrote:
>
>>
>>
>> On 2/10/2012 8:59 AM, Masahiro Nakagawa wrote:
>>
>>> Following code works on dmd 2.057, but causing segmentation fault on dmd 2.058 beta.
>>>
>>> -----
>>> struct S
>>> {
>>>    void foo(V)(in V v)
>>>    {
>>>    }
>>>
>>>    void foo(Args...)(auto ref const Args args)
>>>    {
>>>        foreach (i, T; Args)
>>>            foo(args[i]);
>>>    }
>>> }
>>>
>>> void main()
>>> {
>>>    S s;
>>>    s.foo(10);
>>> }
>>> ----
>>>
>>> Does anyone report this issue?
>>> This bug is critical for my msgpack-d and related libraries.
>>>
>>>
>> This compiles for me without error. When it runs, I get a stack overflow. The reason looks clear - foo(Args) is recursively calling itself. I don't think it's a bug in dmd.
>>
>
>  I retried above code using new beta on two environments.
>
>  Mac OS X 10.6.8 causes segmentation fault, but
> Scientific Linux release 6.0 64bit works fine.
>
>  Does D allow above code?
>
>
> Do you mean the compiler seg faults or the compiled program seg faults?
>

In Mac, compiled program seg faults.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120211/96f52505/attachment.html>