[Issue 15420] topN(Range, Range) does not respect its less predicate

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15420

--- Comment #1 from Infiltrator  ---
https://github.com/D-Programming-Language/phobos/pull/3863

--

[Issue 15420] New: topN(Range, Range) does not respect its less predicate

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15420

  Issue ID: 15420
   Summary: topN(Range, Range) does not respect its less predicate
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: lt.infiltra...@gmail.com

=
import std.algorithm;
import std.stdio;

void main() {
   int[] a = [ 5, 7, 2, 6, 7 ];
   int[] b = [ 2, 1, 5, 6, 7, 3, 0 ];
   topN!"a > b"(a, b);
   sort!"a > b"(a);
   assert(a == [ 7, 7, 7, 6, 6 ]);
}
=

The above code fails on the assertion because topN has ignored the predicate
given to it.

--

[Issue 5691] walkLength() compatible with opApply()

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5691

--- Comment #17 from bb.t...@gmx.com ---
(In reply to ag0aep6g from comment #16)
> (In reply to Andrei Alexandrescu from comment #15)
> > Sorry. (I think it was me who closed it - how can I see who did?)
> 
> It wasn't you. bb.temp closed it without comment. You can see it on the
> "History" page:
> https://issues.dlang.org/show_activity.cgi?id=5691
> The link to that page is in the right column of the issue details, in
> parentheses behind the "Modified" date. Or just search the page for
> "History".

Based on the previous argumentation (see J.M.Davis) and the time elapsed since
the report, I took the initiative to close. If it's an error, sorry. 

It's off topic but the fact is that there is a lot of phobos issues whose
validity is discutable. Among the old reports, most of the
invalid/already-fixed ones are closed now. Time to stop my initiative to find
more of them, I guess.

--

[Issue 5691] walkLength() compatible with opApply()

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5691

--- Comment #18 from Steven Schveighoffer  ---
FWIW, I agree with Andrei here (now). For one thing, walkLength would have to
add the complexity of trying to infer the right parameters to pass to foreach.

opApply has some usefulness, but much of it has been eroded. There are only a
couple of advantages left: 1. ability to use recursion during iteration, 2.
overloading based on loop variable types.

--

[Issue 15416] New: UFCS does not attempt to derefence (but should it?)

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15416

  Issue ID: 15416
   Summary: UFCS does not attempt to derefence (but should it?)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lt.infiltra...@gmail.com


class C { int x; void bar() { } }
void foo(C) { }

void main() {
auto c = new C;
auto d = 
d.bar; // d.bar (C*) does multiple derefs to c.bar (C)
d.foo; // d.foo does not attempt to deref d (C*) to c (C)
}

/d690/f182.d(8): Error: function f182.foo (C _param_0) is not callable using
argument types (C*)



This leads to inconsistent behaviour between UFCS functions and true methods. 
However, should this behaviour be changed for UFCS functions?  If it's not
extended to non-UFCS functions, it will lead to inconsistent behaviour again
(d.foo would work but foo(d) would not).

But if it's extended to all functions, this could get messy for all other
functions.

--

[Issue 15416] UFCS does not attempt to derefence (but should it?)

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15416

Infiltrator  changed:

   What|Removed |Added

 CC||and...@erdani.com,
   ||bugzi...@digitalmars.com

--

[Issue 314] [module] Static, renamed, and selective imports are always public

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=314

Paolo Invernizzi  changed:

   What|Removed |Added

 CC||paolo.inverni...@gmail.com

--

[Issue 5691] walkLength() compatible with opApply()

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5691

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ag0ae...@gmail.com
 Resolution|INVALID |---

--- Comment #14 from ag0ae...@gmail.com ---
Reopening.

If this gets closed, I think it should be closed as WONTFIX, not as INVALID.
The request itself is not unreasonable. The argument against it is that the
added complexity isn't worth the functionality.

Generally, please give your reasoning when closing issues, especially when you
haven't taken part in the discussion.

--

[Issue 15407] Assert hit in toElem e2ir.c:1962

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15407

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #3 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5303

--

[Issue 10087] std.range.chunks problem with chunkSize = 0

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=10087

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to bb.temp from comment #2)
> You have an assertion for this in Chunk ctor, so you can detect the problem
> when testing.

The assert needs to be documented, though:
https://github.com/D-Programming-Language/phobos/pull/3858

--

[Issue 5691] walkLength() compatible with opApply()

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5691

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #15 from Andrei Alexandrescu  ---
Sorry. (I think it was me who closed it - how can I see who did?) Yes, that's
the reason - at some point we've got to pare down what we support. Reclosing
(sic) as WONTFIX.

--

[Issue 5691] walkLength() compatible with opApply()

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5691

--- Comment #16 from ag0ae...@gmail.com ---
(In reply to Andrei Alexandrescu from comment #15)
> Sorry. (I think it was me who closed it - how can I see who did?)

It wasn't you. bb.temp closed it without comment. You can see it on the
"History" page:
https://issues.dlang.org/show_activity.cgi?id=5691
The link to that page is in the right column of the issue details, in
parentheses behind the "Modified" date. Or just search the page for "History".

--

[Issue 15417] New: Wrong parameter passing for variadic nested functions within aggregate

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15417

  Issue ID: 15417
   Summary: Wrong parameter passing for variadic nested functions
within aggregate
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mathias.l...@sociomantic.com
CC: pub...@dicebot.lv

```
import core.stdc.stdarg;

class C
{
private void method ()
{
void test (ulong c1, ...)
{
va_list ap;
va_start(ap, _argptr);
assert(char.init == va_arg!(char)(ap));
}
test(4242UL, char.init);
}
}

void main ()
{
auto c = new C;
c.method;
}
```

Result in a SEGV:

```
Program received signal SIGSEGV, Segmentation fault.
core.stdc.stdarg.va_arg!(char).va_arg(core.stdc.stdarg.__va_list_tag*, ref
char) (parmn=@0x7fffd6c0: 255 '\377', apx=0x0)
at /usr/include/dmd/druntime/import/core/stdc/stdarg.d:233
233if (ap.offset_regs < 6 * 8 && T.sizeof <= 8)
(gdb) bt
#0  core.stdc.stdarg.va_arg!(char).va_arg(core.stdc.stdarg.__va_list_tag*, ref
char) (parmn=@0x7fffd6c0: 255 '\377', apx=0x0)
at /usr/include/dmd/druntime/import/core/stdc/stdarg.d:233
#1  0x0041f391 in
core.stdc.stdarg.va_arg!(char).va_arg(core.stdc.stdarg.__va_list_tag*) (ap=0x0)
at /usr/include/dmd/druntime/import/core/stdc/stdarg.d:198
#2  0x0041f33b in vararg.C.method().test(ulong, ...) (
this=0x77eec000, _arguments_typeinfo=0x648360 , 
c1=4242) at vararg.d:11
#3  0x0041f2d7 in vararg.C.method() (this=0x77eec000)
at vararg.d:13
#4  0x0041f36a in D main () at vararg.d:20

```

Tested with struct too.
Tested with 2.066.1, 2.069, and master as of now (v2.069-devel-4afb98f)

--

[Issue 15418] New: Warning 178: .LIB pagesize exceeds 512

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15418

  Issue ID: 15418
   Summary: Warning 178: .LIB pagesize exceeds 512
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: m...@mikewey.eu

When GtkD is compiled with debug information, which is the default for dub.

linking executables results in the following warning:

> Warning 178: .LIB pagesize exceeds 512

after that optlink either hangs or terminates.

The GtkD library was compiled with the dmd -lib switch.
or dub build gtk-d:gtkd

The executable with the following command:
dmd HelloWorld.d -I..\..\src ..\..\gtkd.lib

--

[Issue 15418] Warning 178: .LIB pagesize exceeds 512

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15418

--- Comment #1 from Mike Wey  ---
First reported in GtkD issue 133.

https://github.com/gtkd-developers/GtkD/issues/133

--

[Issue 15419] New: std.conv.parse() does not accept string literals

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15419

  Issue ID: 15419
   Summary: std.conv.parse() does not accept string literals
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: trivial
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: thomas.bock...@gmail.com

>From the std.conv.parse() unittests:

// @@@BUG@@@ the size of China
// foreach (i; 2..37)
// {
//  assert(parse!int("0",i) == 0);
//  assert(parse!int("1",i) == 1);
//  assert(parse!byte("10",i) == i);
// }
foreach (i; 2..37)
{
string s = "0";
assert(parse!int(s,i) == 0);
s = "1";
assert(parse!int(s,i) == 1);
s = "10";
assert(parse!byte(s,i) == i);
}
// Same @@@BUG@@@ as above
//assert(parse!int("0011001101101", 2) == 0b0011001101101);
// assert(parse!int("765",8) == 0765);
// assert(parse!int("fCDe",16) == 0xfcde);
auto s = "0011001101101";
assert(parse!int(s, 2) == 0b0011001101101);
s = "765";
assert(parse!int(s, 8) == octal!765);
s = "fCDe";
assert(parse!int(s, 16) == 0xfcde);

This is caused by `parse()` using pass-by-ref for the first argument, which
does not support rvalues since `scope ref` isn't implemented yet.

--

[Issue 15336] std.json: opIn undocumented for JSONValue

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15336

--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/e60c9dcf18b1b42d3b131840f975f1588ce6761d
Merge pull request #3857 from BBasile/issue-15336

fix issue 15336, opIn undocumented for JSONValue

--

[Issue 15336] std.json: opIn undocumented for JSONValue

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15336

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15419] std.conv.parse() does not accept string literals

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15419

thomas.bock...@gmail.com changed:

   What|Removed |Added

   Severity|trivial |enhancement

--- Comment #3 from thomas.bock...@gmail.com ---
I just realized that you were the one who changed the importance to
"enhancement".

I thought I had just forgotten to set it initially, since "enhancement" is the
default; I wasn't trying to undo your change.

--

[Issue 15419] std.conv.parse() does not accept string literals

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15419

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15419] std.conv.parse() does not accept string literals

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15419

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/8da9dbc2ae7a80be15a9cda8e5824cb9501178b1
Merge pull request #3861 from tsbockman/size_of_china

Fix Issue 15419 - "@@@BUG@@@ the size of China"

--

[Issue 15419] std.conv.parse() does not accept string literals

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15419

thomas.bock...@gmail.com changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

--- Comment #5 from thomas.bock...@gmail.com ---
Marking this as WONTFIX.

A real fix would either:
1) Use `scope ref`, if it is ever implemented, or
2) Use the `auto ref` like so (to minimize template bloat):

template parse(Target, Source)
if(/+constraints+/)
{
private Target impl(ref Source s)
{
/+implementation+/
}

pragma(inline, true)
Target parse(auto ref Source s)
{
return impl(s);
}
}

The later should completely fix the problem, and be fully backwards compatible.
However, it would be a large diff and might confuse ddoc, too.

--

[Issue 15419] std.conv.parse() does not accept string literals

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15419

thomas.bock...@gmail.com changed:

   What|Removed |Added

   Severity|enhancement |trivial

--- Comment #2 from thomas.bock...@gmail.com ---
I'll close this once the unittest has been cleaned up, then.

It would still be cool to see this a real fix with `scope ref` some day,
though.

--

[Issue 15419] std.conv.parse() does not accept string literals

2015-12-07 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15419

yebblies  changed:

   What|Removed |Added

 CC||yebbl...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|trivial |enhancement

--- Comment #1 from yebblies  ---
>From the description of parse:
'takes the input by reference and advances it to the position following the
conversion'

This is intentional API design, and therefore not a bug.

The compiler used to be very sloppy about what it accepted as an lvalue, so
those test cases did work at one point.

The workaround is just to use 'to' instead of 'parse', which takes an rvalue
argument.

--