[Issue 18804] std.algorithm.mutation.copy puts whole source range into target range when it should put elements

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18804

ag0aep6g  changed:

   What|Removed |Added

   Keywords||pull
 CC||ag0ae...@gmail.com
  Component|dmd |phobos
   Hardware|x86 |All
Summary|Side effects incorrectly|std.algorithm.mutation.copy
   |optimized out when results  |puts whole source range
   |are discarded   |into target range when it
   ||should put elements
 OS|Windows |All

--- Comment #1 from ag0aep6g  ---
Generally, please post complete code, including imports. Also include the
contents of other files like "in".

What happens here is that `copy` puts the range as a whole into the NullSink.
This is not DMD optimizing anything out.

Reduced test case:


import std.algorithm.mutation: copy;

struct NullSink
{
void put(E)(E) {}
}

int line = 0;

struct R
{
int front;
@property bool empty() { return line == 1; }
void popFront() { line = 1; }
}

void main()
{
R r;
copy(r, NullSink());
assert(line == 1); /* fails; should pass */
}


Pull request to fix this:
https://github.com/dlang/phobos/pull/6485

--


[Issue 14619] foreach implicitly slices ranges

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14619

ag0aep6g  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18807

--


[Issue 18807] RefRange behaves very differently for Input Ranges and Forward Ranges

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18807

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14619

--- Comment #1 from ag0aep6g  ---
Possibly a duplicate of issue 14619.

--


[Issue 18812] New: template enforce should accept same parameter combos as exception

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18812

  Issue ID: 18812
   Summary: template enforce should accept same parameter combos
as exception
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: elpenguin...@gmail.com

Currently, the enforce!SomeException form of enforce can use only msg/file/line
combinations. I believe this is an unnecessary restriction and this form of
enforce should be able to use any constructor for SomeException as long as
enforce's parameters match up - for example:

`
class SomeException : Exception {
uint somethingMeaningful;
this(uint a) {
somethingMeaningful = a;
super("Something went wrong!");
}
}

enforce!SomeException(false, 4);
`

Removing this restriction would be a HUGE usability improvement and would make
this much more viable in @nogc code.

--


[Issue 18789] std.stdio messes up UTF conversions on output

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18789

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

https://github.com/dlang/phobos/commit/d5cc4c5087a1819ac716cb5ea11d988fa667f822
fix conversion from wchar to char in LockingTextWriter.put

Fixes the easier part of issue 18789.

--


[Issue 18810] root/ctfloat depends upon backend

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18810

Richard Cattermole  changed:

   What|Removed |Added

 CC||alphaglosi...@gmail.com

--


[Issue 18811] root/array.d leaks

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18811

Richard Cattermole  changed:

   What|Removed |Added

 CC||alphaglosi...@gmail.com

--


[Issue 18811] New: root/array.d leaks

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18811

  Issue ID: 18811
   Summary: root/array.d leaks
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alphaglosi...@gmail.com

With -version=GC root/array.d will leak memory.
But only when dim is 1.

This is because it is putting it into smallarray, instead of allocating memory.

It can be verified by setting SMALLARRAYCAP to 0 and removing the if statement
in the destructor.

During my testing with dmd as a library it will result in ~0.5mb leakage. The
test cases were small, but in much larger cases this could be quite serious for
reusability.

This could be a by product of other issues, I do not know.

--


[Issue 18810] New: root/ctfloat depends upon backend

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18810

  Issue ID: 18810
   Summary: root/ctfloat depends upon backend
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alphaglosi...@gmail.com

For Windows using -m64 or -m32mscoff root/ctfloat depends upon the backend for
the symbols ld_sprint and strtold_dm.

They are defined in el.c and strtold.c.

This is a blocker for dmd as a library depending upon how it is used.

LDC[0] has outright removed both symbols.

[0]
https://github.com/ldc-developers/ldc/blob/a9c76cff3af12aca3d5335633f14fd51a7416682/dmd/root/ctfloat.d#L38

--


[Issue 18809] New: Improve error message on nonexistent property

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18809

  Issue ID: 18809
   Summary: Improve error message on nonexistent property
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dl...@ryanjframe.com

The following code:

---
struct SomeStruct {}

void main() {
auto s = SomeStruct();
s.nonexistent = "hello";
}
---

yields the error message:

"source\app.d(5,6): Error: no property nonexistent for type SomeStruct"

Here, that's not a problem. But if SomeStruct was defined in another module,
especially in a large or unfamiliar project, it would be helpful to have the
fully qualified name to quickly identify the location of the type's definition:

"source\app.d(5,6): Error: no property nonexistent for type app.SomeStruct"

--


[Issue 18808] New: dmd not found after installation using script

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18808

  Issue ID: 18808
   Summary: dmd not found after installation using script
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: bachm...@yahoo.com

If I install using the script

curl -fsS https://dlang.org/install.sh | bash -s dmd

It gives the message

Run `source ~/dlang/dmd-2.079.1/activate` in your shell to use dmd-2.079.1.
This will setup PATH, LIBRARY_PATH, LD_LIBRARY_PATH, DMD, DC, and PS1.

That works until you close the current terminal. As soon as you use a new
terminal, you get

Command 'dmd' not found

On Ubuntu 18.04. I put the severity at critical because the installation
process needs to work.

--


[Issue 18807] New: RefRange behaves very differently for Input Ranges and Forward Ranges

2018-04-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18807

  Issue ID: 18807
   Summary: RefRange behaves very differently for Input Ranges and
Forward Ranges
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: major
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Example program:

import std.range: refRange, iota;

struct R1 {
auto r = iota(3);
alias r this;
}
void works() {
R1 r1;
foreach(x; refRange()) {}
assert(r1.empty);
}

struct R2 {
auto r = iota(3);
alias r this;
@property auto save() { return this; }
}
void explodes() {
R2 r2;
import std.range;
foreach(x; refRange()) {}
assert(r2.empty);   // <-- BOOM
}

works() is fine.
explodes() fails on the assertion.

The only difference is that R2 defines save().

What happens is that the foreach calls opSlice (if it exists), which calls
save. opSlice exists iff save exists.

Upgrading an existing input range to a forward range invisibly breaks any code
that used foreach on a refRange of that range.

--