February 10, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Masahiro Nakagawa | >> 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);
}
|
February 10, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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
|
February 10, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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
|
February 11, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Masahiro Nakagawa | 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> |
February 11, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
February 11, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak |
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 ??
|
February 11, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | // 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> |
February 11, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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> |
February 11, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | 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);
}
|
February 11, 2012 [dmd-beta] D2 2.058 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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> |
Copyright © 1999-2021 by the D Language Foundation