[Issue 12029] Swap on std.container.Array?

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12029

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #3 from bb.t...@gmx.com ---
swap() now works on Array:

___
void main() {
import std.algorithm;
import std.container: Array;
auto arr = Array!int([1, 2]);
swap(arr[0], arr[1]);
assert(arr[0] == 2 && arr[1] == 1);
}___

--


[Issue 13099] @nogc std.range.stride

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13099

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--


[Issue 12865] splitLines returns empty array on empty string

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12865

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |INVALID

--- Comment #2 from bb.t...@gmx.com ---
No your wrong Temtaime,because [``] as result would mean that the input
argument contained one empty string:


___
import std.string;

void main()
{
assert( splitLines("\n") == [``]); // ok
}___

--


[Issue 5520] bitfieldsOn

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5520

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #5 from bb.t...@gmx.com ---
implemented in https://github.com/rtcvb32/phobos/pull/1/files

--


[Issue 12861] std.algorithm.sort of core.simd.int4[] too

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12861

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bb.t...@gmx.com ---
2.069 ok

--


[Issue 12840] @nogc std.range.iota(x, y, step)

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12840

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bb.t...@gmx.com ---
2.069 ok now

--


[Issue 15296] [REG2.069] cannot inline simple function that calls use non-inlinable statements

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15296

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/4c0c8088d34aca637aef07122ec8a26ce1244fe3
fix Issue 15296 - cannot inline simple function that calls use non-inlinable
statements

Add workaround to do inlining same with the old code.

https://github.com/D-Programming-Language/dmd/commit/6a407df2384446cb14eea854860e391c5db59377
Merge pull request #5277 from 9rnsr/fix15296

[REG2.069] Issue 15296 - cannot inline simple function that calls use
non-inlinable statements

--


[Issue 15369] [REG master] id.d(369): Error: Outside Unicode code space

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15369

Kenji Hara  changed:

   What|Removed |Added

Summary|id.d(369): Error: Outside   |[REG master] id.d(369):
   |Unicode code space  |Error: Outside Unicode code
   ||space

--- Comment #2 from Kenji Hara  ---
This is git-head only regression. Same issue does not exist in 2.069.1 or
earlier releases.

--


[Issue 12767] writeln of a struct with toString returning char[N]

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12767

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #3 from bb.t...@gmx.com ---
2.069 ok

--


[Issue 5743] readf cannot read wchar or dchar from UTF-8 stdin

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5743

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #3 from bb.t...@gmx.com ---
2.069, works now, test with ö and é as well.

--


[Issue 13608] std.range range interfaces hide @safe-ness

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13608

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bb.t...@gmx.com ---
pass in 2.069

--


[Issue 13177] There may be a problem with std.bitmanip.BitArray and the "in" operator of associative arrays?

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13177

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bb.t...@gmx.com ---
this is the case now. you get true in your output (tba in ha)

--


[Issue 15369] id.d(369): Error: Outside Unicode code space

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15369

Kenji Hara  changed:

   What|Removed |Added

   Keywords||wrong-code
   Severity|normal  |regression

--- Comment #1 from Kenji Hara  ---
Reduced test case (Note that the reproduction ratio is not 100%):

import core.stdc.stdio;

struct Msgtable
{
const(char)[] ident;
const(char)* name;
};

Msgtable[] msgtable =
[
{ "empty", "" },
];

void main()
{
auto id = msgtable[0].ident;
auto p = msgtable[0].name;

printf("empty -> p = %p >>>%s<<<\n", p, p);
}


Introduced in:
https://github.com/D-Programming-Language/dmd/pull/5220

--


[Issue 10191] std.array.array and Unicode strings

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10191

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bb.t...@gmx.com ---
2.069 ok

--


[Issue 13608] std.range range interfaces hide @safe-ness

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13608

Brad Roberts  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #2 from Brad Roberts  ---
That unittest, now in std/algorithm/iteration.d, isn't marked pure yet. 
Looking at std.range.interfaces, only one test is marked @pure.  For this to be
closed, unit tests are needed.

--


[Issue 6663] std.stdio conflicts with core.stdc.stdio

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=6663

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |INVALID

--- Comment #6 from bb.t...@gmx.com ---
invalid, see pantaleev comment.

--


[Issue 11572] eager apply for ranges

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=11572

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #5 from bb.t...@gmx.com ---
solved since each() implemented 

https://github.com/D-Programming-Language/phobos/pull/2024

--


[Issue 15366] Enum typed as bool behaves as bool even when cast

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15366

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

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

--


[Issue 13654] @nogc std.range.enumerate

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13654

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--


[Issue 15366] Enum typed as bool behaves as bool even when cast

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15366

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

https://github.com/D-Programming-Language/dmd/commit/67a21a9ec222e63ad5bab445662de9114878bc90
fix Issue 15366 - Enum typed as bool behaves as bool even when cast

>From a CastExp 'a && b', its `semantic` returns an `AndAndExp` with the 'Enum'
type.
But if its `semantic` will be called once more, it will repaint its `type` to
'bool'.

Same problem exists in `OrOrExp`.

https://github.com/D-Programming-Language/dmd/commit/913ffbe000e99e3a2aa6caaea9994a103503d6ac
Merge pull request #5279 from 9rnsr/fix15366

Issue 15366 - Enum typed as bool behaves as bool even when cast

--


[Issue 3862] std.file.copy does not have the same behavior as cp

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3862

--- Comment #12 from Vladimir Panteleev  ---
(In reply to Jonathan M Davis from comment #11)
> @Vladimir Well, clearly you and I have very different expectations when
> copying files.

You haven't addressed any of the arguments I brought up.

> So, if we're not going to fix std.file.copy to work like cp, and I
> want a usable copy function, I'm clearly going to have to find the time to
> write one myself and use that, and then I'll avoid std.file.copy like the
> plague.

In that case, I'll have to keep in mind to avoid any code you write like a
plague ;) Because as I explained, in most situations using such a function is
just wrong, and will result in buggy programs that crash in strange places if
something doesn't go according to its plan.

--


[Issue 12624] [REG 2.064] Internal error: backend\cgobj.c 2313 with Rebindable!(immutable TimeZone) in std.datetime

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12624

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com
Summary|Internal error: |[REG 2.064] Internal error:
   |backend\cgobj.c 2313 with   |backend\cgobj.c 2313 with
   |Rebindable!(immutable   |Rebindable!(immutable
   |TimeZone) in std.datetime   |TimeZone) in std.datetime
   Severity|blocker |regression

--- Comment #6 from Vladimir Panteleev  ---
This is a regression.

Introduced in https://github.com/D-Programming-Language/dmd/pull/2369

--


[Issue 15369] [REG master] id.d(369): Error: Outside Unicode code space

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15369

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

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

--


[Issue 3862] std.file.copy does not have the same behavior as cp

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3862

--- Comment #11 from Jonathan M Davis  ---
@Vladimir Well, clearly you and I have very different expectations when copying
files. What I expect and what is pretty much exactly what cp does. e.g. with
cp, I always use directory for the target and never provide a file name unless
I'm renaming the file. And I screw it up every time that I use std.file.copy.
I've just never gotten around to fixing it like I should have. So, if we're not
going to fix std.file.copy to work like cp, and I want a usable copy function,
I'm clearly going to have to find the time to write one myself and use that,
and then I'll avoid std.file.copy like the plague.

> 6. Do you know any programming languages whose copy function from their 
> standard library behaves like cp in this regard?

D is the only language that I use with any regularity that even declares a copy
function. So, my primary experience with copying files is cp, and cp's behavior
is what I expect. I find std.file.copy's behavior to be very unfriendly in
comparison.

--


[Issue 3862] std.file.copy does not have the same behavior as cp

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3862

--- Comment #14 from Jonathan M Davis  ---
(In reply to Vladimir Panteleev from comment #12)
> (In reply to Jonathan M Davis from comment #11)
> > @Vladimir Well, clearly you and I have very different expectations when
> > copying files.
> 
> You haven't addressed any of the arguments I brought up.

I can see some corner cases where your concerns would be a problem, but in
general, cp does exactly what I want, and having to do a bunch of additional
checks is just annoying. And while I can definitely believe that there are
programs where race conditions would be a concern or where it could be
problematic to assume that the target is a directory, I've never personally
written or worked on a program where that was a concern.

(In reply to Vladimir Panteleev from comment #13)
> I just looked at Python, and it provides both variants. We could introduce
> "copyTo" which works in the same way, and perhaps also require that the path
> ends with a directory separator for the "copy inside directory" behavior to
> activate.

Requiring a terminating directory separator would be annoying, but having
separate functions where one requires that the target be a file and the other
is more liberal does make sense.

--


[Issue 12507] SysTime.init.toString should not segfault

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12507

--- Comment #6 from Jonathan M Davis  ---
(In reply to Alaksiej Stankievič from comment #5)
> What is currently status of this?
> 
> I have hit this just now, and it consumes 1 hour of investigation.

As the "Depends on" field indicates, it's blocked by issue# 12624. Attempting
to provide a default TimeZone to SysTime won't compile on Windows due to a bug
in the compiler backend.

--


[Issue 13301] Inline ASM documentation does not allow string literals

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13301

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

https://github.com/D-Programming-Language/dlang.org/commit/34d6b17582002eb1f3178c77664e459b555d7c4b
Issue 13301 - Inline ASM documentation does not allow string literals

https://github.com/D-Programming-Language/dlang.org/commit/20b34f54aaeb876b545bac1d34b954db15f0a237
Merge pull request #860 from Hackerpilot/issue-13301

Issue 13301 - Inline ASM documentation does not allow string literals

--


[Issue 3862] std.file.copy does not have the same behavior as cp

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3862

--- Comment #13 from Vladimir Panteleev  ---
(In reply to Vladimir Panteleev from comment #12)
> In that case, I'll have to keep in mind to avoid any code you write like a
> plague ;)

OK, sorry, that was over the top.

(In reply to Jonathan M Davis from comment #11)
> D is the only language that I use with any regularity that even declares a
> copy function. So, my primary experience with copying files is cp, and cp's
> behavior is what I expect. I find std.file.copy's behavior to be very
> unfriendly in comparison.

I just looked at Python, and it provides both variants. We could introduce
"copyTo" which works in the same way, and perhaps also require that the path
ends with a directory separator for the "copy inside directory" behavior to
activate.

--


[Issue 15370] New: Some way to manually allocate the closure for delegates to nested functions.

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15370

  Issue ID: 15370
   Summary: Some way to manually allocate the closure for
delegates to nested functions.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: joeyemm...@yahoo.com

There has been a strong push to move away from the GC, being able to allocate
closures with out it would be another step in that direction. As far as I can
tell there is no current way to manually allocate a closure. It would be great
if there was a solution that could work with allocators to be able to manually
allocate closures. 

Example:
auto foo(int x)
{
   int bar(){ return x; }
   return  
   // implicitly allocates a closure with the gc
   // No way to manually allocate it currently 
}

Maybe it could be something as simple as __traits(setClosureAllocator,
Mallocator.instance); to set the allocator for the closure of the current
function. 

Allocators then would need to handle the case of freeing the delegate closure
as well.

--


[Issue 15335] getSymbolsByUDA fails if type has private members

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15335

bb.t...@gmx.com changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #3 from bb.t...@gmx.com ---
I've looked at your PR on GH and obviously the first one is better since it
just prevents the error.

The accessibility is a more global problem. Every time someone will put a
function related to traits in a module and use this function in another module
the same error will pop up. A mixin template allows to inject the function
related to traits in the module it's used. So far it's ok, let's say for a
private usage, (actually there's --0-- mixin template in phobos so I doubt
they'll ever accept some new functions based on this, even if it works).

Maybe the real solution would be to make "__traits(getMember,...)", and more
generally speaking all the traits verbs that might also block compilation
because of this, able to return any member, regardless of the protection.

Then it would be up to the user to respect or not the protection using an
additional "__traits(getProtection,...)" to filter an item in the traits code.

--


[Issue 15366] Enum typed as bool behaves as bool even when cast

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15366

--- Comment #2 from Lionello Lunesu  ---
Adding an explicit "this." fixed the issue:

enum Enum : bool { A, B };
struct I{
void func(Enum e);
void func2(Enum a, Enum b) {this.func(cast(Enum)(a&));}
}

Something happens when the compiler adds the "this" in your behalf. The
resolution changes.

--


[Issue 10039] std.algorithm enhancements: min, max, clamp

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10039

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #12 from bb.t...@gmx.com ---
min(), max() & clamp() are all in std.algorithm.comparison now.

--


[Issue 15371] New: __traits(getMember) should bypass the protection

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15371

  Issue ID: 15371
   Summary: __traits(getMember) should bypass the protection
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bb.t...@gmx.com

"__traits(getMember,...)" should always work, whatever is the member protection
(as long as the symbol is a valid one).

The current limitation is problematic because it prevents to write functions
related to traits in a separate dedicated modules (e.g mylib.traits)

Every time a "__traits(getMember,...)" has to be used the only solution to make
it works with a private member is to write again and again the code (or to warp
the function in a mixin template).

Since there is also the traits verb "getProtection", it still would be possible
to respect the protection or not.

In case this wouldn't be clear, more concretly:

==
module mylib.traits;

mixin template ScopedReachability()
{
bool isMemberReachableGood(T, string member)()
if (is(T==class) || is(T==struct))
{
return __traits(compiles, __traits(getMember, T, member));
}
}
bool isMemberReachableBad(T, string member)()
if (is(T==class) || is(T==struct))
{
 return __traits(compiles, __traits(getMember, T, member));
}

=
module somemodule;

class Foo
{
private: 
uint a,b,c;
public:
this()
{
foreach(member; __traits(allMembers, Foo))
static if (isMemberReachableBad!(Foo, member)) {/*a,b,c not detected*/}

import mylib.traits;
mixin ScopedReachability; // isMemberReachableGood is now a local func. 
static if (isMemberReachableGood!(Foo, member)) {/*a,b,c detected*/} 
}
}

=

With a relaxed protection policy on the "getMember" verb, it would be possible
to write reusable functions related to traits. Actually the problem prevents a
lot of good template that would simplify the traits usage to be written.

=

see also:

- https://issues.dlang.org/show_bug.cgi?id=15335
- http://forum.dlang.org/post/xrrptwihnvlxabswn...@forum.dlang.org

--


[Issue 15371] __traits(getMember) should bypass the protection

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #1 from bb.t...@gmx.com ---
something like that:

https://github.com/Blumerline/dmd/commit/53419e71b93b0870574d93cbb83ebb7ccbb5e325

or maybe change in the Scope struct the module that indicates where the
template should be instantiated (since it function that contains traits code
will always be a template).

--


[Issue 11015] BitArray.opCom is invalid on 64 bit machines

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=11015

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |FIXED

--


[Issue 4766] Function to load a whole HTML page

2015-11-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=4766

bb.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bb.t...@gmx.com
 Resolution|--- |WORKSFORME

--