[Issue 14403] DDox: std.algorithm index links are 404

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14403

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/8e12e01f388097bc947ef8e7ace1fef5926b3521
Merge pull request #1322 from s-ludwig/master

Fix formatting of (M)REF_ALTTEXT. See issue 14403.

--


[Issue 9646] std.algorithm.splitter for strings has opportunities for improvement

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=9646

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a9d5b8ca779d2dd89c8b49abae385e793d469e5d
Improve speed of find for random access needles (strings)

For find a string within a string, std.algorithm.searching.find was
unnecessarily slow. The reason is it created intermediate slices. A
naively written nested-for-loop implementation was a few times
faster.

For random access ranges (which strings are) this uses an index based
algorithm, which does not need to create an intermediate slice. Speed
is now comparable to the nested-for-loop implementation even in rather
pathological cases.

This might help with issue 9646.

--


[Issue 9370] DDoc: switch to one html file per entity (function, type etc)

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=9370

Sönke Ludwig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Sönke Ludwig  ---
I think this can be closed safely now.

--


[Issue 14403] DDox: std.algorithm index links are 404

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14403

Sönke Ludwig  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Sönke Ludwig  ---
Phobos PR: https://github.com/dlang/phobos/pull/4395
dlang.org PR: https://github.com/dlang/dlang.org/pull/1322

--


[Issue 16073] Ranges without opDollar not supported

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16073

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a818c7e059bf0e37609c7030b8306daf54909beb
[Issue 16073] Fix incorrect uses of random access range primitives in
std.algorithm.iteration

https://github.com/dlang/phobos/commit/3a1db06f41eca48e1b1b46ca05bb221c01714160
[Issue 16073] Fix incorrect uses of random access range primitives in
std.algorithm.mutation

https://github.com/dlang/phobos/commit/74398e70cf79acab6a352e7bbec614ce2f91dffb
[Issue 16073] Fix incorrect uses of random access range primitives in
std.algorithm.searching

https://github.com/dlang/phobos/commit/e216c10b2ce08cb8ae5c64983a2f24367f4b86e4
Merge pull request #4383 from JackStouffer/issue16073

Partial Fix for Issue 16073

--


[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13348

--- Comment #9 from Steven Schveighoffer  ---
(In reply to Dmitry Olshansky from comment #7)
> Should I just use GC?

At this point, if we were to fix purity, I think this is the way to go. From
your comments in the code, you said that most of the time allocations will not
happen. I'm sure this varies with the language being processed, but it's
probably mostly true.

One other nice benefit about using the GC is you can remove the requirement to
copy the current grapheme if it's on the heap (and make that immutable also, so
Grapheme can be passed to another thread if the wrapped range allows it), and
copying the struct itself would be less expensive.

If we were to wait for pure-compatible reference counting to materialize, this
would be the ideal mechanism.

(In reply to hsteoh from comment #8)
> Here's a thought, I don't know how feasible it is, but what about using
> slices of the input string, and decode on demand?

Not a big fan of this idea. It puts extra demand on the wrapped range type
(must be sliceable or at least forward range), and might make things slower in
the case where the stack-allocated part of the union would be sufficient.

--


[Issue 15908] Implicitly typed lambda inside class "has no value"

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15908

John Colvin  changed:

   What|Removed |Added

   Keywords||CTFE, rejects-valid

--


[Issue 15908] Implicitly typed lambda inside class "has no value"

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15908

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from John Colvin  ---
I just hit this as well in slightly different circumstances. It appears to be a
long-standing bug, I couldn't find an older compiler version that it worked
with (haven't tried bisecting though).

I'm pretty sure it's ctfe specific.

--


[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13348

--- Comment #8 from hst...@quickfur.ath.cx ---
Here's a thought, I don't know how feasible it is, but what about using slices
of the input string, and decode on demand? Of course, this doesn't work for
general input ranges (have to allocate somehow in that case), but conceivably
it could be done for ranges with hasSlicing?  Or, for forward ranges, use
.save. Obviously, this will depend on whether .save allocates, but then it's
the user's problem, not ours.

The advantage is that we don't have to allocate at all, at least in some cases.
The disadvantage is that you'll need to decode again every time grapheme
members are accessed. It may cause poor performance.

--


[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13348

--- Comment #7 from Dmitry Olshansky  ---
> OK, so pretty much all the problems stem from malloc/realloc/free being used 
> to manage the memory of the Grapheme type.

Should I just use GC?

--


[Issue 16116] New: Infinite loop on (somewhat complex) simd math

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16116

  Issue ID: 16116
   Summary: Infinite loop on (somewhat complex) simd math
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: jbc.enge...@gmail.com

DMD 2.071.0 hangs on:
```
import core.simd;

void foo() {
ushort8 src;
ushort8 dest;
ushort src0;
dest = ((src * (src0 + 1) + dest * (256 - src0))>>8);
}
```

LDC has the same problem so probably a front-end bug.
Note: I think the ">>" is unsupported by DMD for SIMD.

Related report:
https://issues.dlang.org/show_bug.cgi?id=13841

--


[Issue 13348] std.uni.Grapheme is impure due to using C malloc and friends

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13348

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com
Summary|std.uni.byGrapheme is   |std.uni.Grapheme is impure
   |impure  |due to using C malloc and
   ||friends

--- Comment #6 from Steven Schveighoffer  ---
OK, so pretty much all the problems stem from malloc/realloc/free being used to
manage the memory of the Grapheme type.

There is one obvious fix: isRegionalIndicator can be marked pure nothrow.

we could move the allocation scheme to use the GC instead of C malloc. But I
don't know what this does for performance. As the comments say, most uses will
never use the allocation.

CC Dmitry.

--


[Issue 13348] std.uni.byGrapheme is impure

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13348

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #5 from Steven Schveighoffer  ---
Something doesn't seem right here. byGrapheme is a template function, including
a templated struct. purity should be inferred everywhere here, no?

The code itself seems pretty simple, seems like all the impurity comes from
Grapheme and possibly decodeGrapheme.

--


[Issue 16058] `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16058

--- Comment #3 from Kenji Hara  ---
>From the type qualifier transitivity, immutable(int* delegate()) should be same
with immutable(int* delegate() immutable).

The root problem is in dmd implementation, TypeNext.makeXXX functions. Fixing
those implementation bugs is not difficult.

--


[Issue 13348] std.uni.byGrapheme is impure

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13348

--- Comment #4 from hst...@quickfur.ath.cx ---
It's not a problem that byGrapheme is sometimes impure, but it should not be
the one introducing the impurity. I.e., if the incoming range is pure, then
byGrapheme ought to be also pure.

This can be enforced by not attributing byGrapheme directly, but using a pure
nothrow etc. unittest to ensure any impure/throwing/etc. code actually comes
from the incoming range, not from byGrapheme itself.

--


[Issue 16115] New: [REG2.067] Wrong code with comma operator

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16115

  Issue ID: 16115
   Summary: [REG2.067] Wrong code with comma operator
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: wrong-code
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

/ test.d 
int n;

auto call()
{
//  n = Test.tag;  // Works
return n = Test.tag, null; // Crash
}

struct Test
{
enum tag = 42;
}

void main()
{
call();

assert(n == 42);
}
/

Introduced in https://github.com/dlang/dmd/pull/3979

--


[Issue 14403] DDox: std.algorithm index links are 404

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14403

Sönke Ludwig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|nob...@puremagic.com|slud...@outerproduct.org

--- Comment #1 from Sönke Ludwig  ---
For a proper fix needs a way to implement $(REF_ALTTEXT) for DDOX - probably
via a special built-in macro.

--


[Issue 15552] broken link http://dlang.org/library/std/algorithm/std_algorithm.html inside http://dlang.org/library/std/algorithm/sorting.html

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15552

Sönke Ludwig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||slud...@outerproduct.org
 Resolution|--- |FIXED

--- Comment #1 from Sönke Ludwig  ---
Fixed by https://github.com/dlang/phobos/pull/4303

Not yet deployed, but this is the current state:
http://dtest.thecybershadow.net/artifact/website-e444ecd0247dac801557e90fefe7247b1828f1eb-c8a954d4dd422e0286a7b14f0dfafdfe/web/library-prerelease/std/algorithm/comparison.html

--


[Issue 15673] [dox] atan2 docs have broken formatting

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15673

Sönke Ludwig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||slud...@outerproduct.org
 Resolution|--- |FIXED

--- Comment #5 from Sönke Ludwig  ---
Fix has been deployed.

--


[Issue 15700] Source code links are partially broken

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15700

Sönke Ludwig  changed:

   What|Removed |Added

 CC||slud...@outerproduct.org
   Assignee|nob...@puremagic.com|slud...@outerproduct.org

--- Comment #3 from Sönke Ludwig  ---
Same root cause as https://issues.dlang.org/show_bug.cgi?id=16114

--


[Issue 16114] [ddox] "Improve this page" links broken for package.d modules

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16114

Sönke Ludwig  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|slud...@outerproduct.org

--


[Issue 16114] New: [ddox] "Improve this page" links broken for package.d modules

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16114

  Issue ID: 16114
   Summary: [ddox] "Improve this page" links broken for package.d
modules
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

The link points to [name].d instead of [name]/package.d. See e.g.
http://dlang.org/library/std/datetime.html.

--


[Issue 15656] ddox should recognize special meaning of '_' in ddoc, else may generate broken links.

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15656

Sönke Ludwig  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||slud...@outerproduct.org
 Resolution|--- |FIXED

--- Comment #6 from Sönke Ludwig  ---
The fixed version of the documentation has been deployed. I've opened a
separate issue for the "improve this page" link bug:
https://issues.dlang.org/show_bug.cgi?id=16114

--


[Issue 14608] Enum members should be formatted as a table

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14608

--- Comment #6 from Andrei Alexandrescu  ---
So should we close this?

--


[Issue 15940] ImplicitConversionTargets and class alias in struct

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15940

--- Comment #2 from b2.t...@gmx.com ---
https://github.com/dlang/phobos/pull/4342

--


[Issue 15940] ImplicitConversionTargets and class alias in struct

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15940

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|b2.t...@gmx.com |nob...@puremagic.com

--


[Issue 16064] std.experimental.allocator.dispose can't be used in @nogc blocks

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16064

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|b2.t...@gmx.com |nob...@puremagic.com

--


[Issue 16008] FreeList should implement deallocateAll, as SharedFreeList does

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16008

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|b2.t...@gmx.com |nob...@puremagic.com

--


[Issue 14608] Enum members should be formatted as a table

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14608

Sönke Ludwig  changed:

   What|Removed |Added

   Assignee|ludwig@informatik_dot_uni-l |nob...@puremagic.com
   |uebeck.de   |

--


[Issue 14608] Enum members should be formatted as a table

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14608

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/926b20648ca3b6199ecdc2fbd1d2fdeef45aa280
Upgrade to DDOX 0.15.4 - Fixes the DDOX part of issue 14608.

- Removes per-enum-member pages and instead displays the full enum member
documentation inside of a single table
- Adds template arguments and constraints display for composite types and enums

https://github.com/dlang/dlang.org/commit/f806372cf2b11cc9c64eec9fa061e63c723b494c
Merge pull request #1319 from s-ludwig/master

Upgrade to DDOX 0.15.4 - Fixes the DDOX part of issue 14608.

--


[Issue 14608] Enum members should be formatted as a table

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14608

--- Comment #4 from Sönke Ludwig  ---
PR for the DDOX side: https://github.com/dlang/dlang.org/pull/1319

BTW, an example for a more detailed enum member documentation:
http://dlang.org/phobos/core_memory.html#.GC.BlkAttr.APPENDABLE

--


[Issue 13348] std.uni.byGrapheme is impure

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13348

Thayne  changed:

   What|Removed |Added

 CC||astrotha...@gmail.com

--- Comment #3 from Thayne  ---
I don't think byGrapheme can be pure in general, because, in general, the input
range used doesn't necessarily have pure input methods. For example the input
range could read from I/O.

The solution would probably be to add pure if and only if the front, popFront,
and empty methods of the inputRange are themselves pure.

I'm not sure what the best way to do that would be.

--


[Issue 14601] pthread functions aren't marked @nogc

2016-06-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14601

Thayne  changed:

   What|Removed |Added

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

--