[Issue 18804] std.algorithm.mutation.copy puts whole source range into target range when it should put elements
https://issues.dlang.org/show_bug.cgi?id=18804 ag0aep6gchanged: 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
https://issues.dlang.org/show_bug.cgi?id=14619 ag0aep6gchanged: 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
https://issues.dlang.org/show_bug.cgi?id=18807 ag0aep6gchanged: 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
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
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
https://issues.dlang.org/show_bug.cgi?id=18810 Richard Cattermolechanged: What|Removed |Added CC||alphaglosi...@gmail.com --
[Issue 18811] root/array.d leaks
https://issues.dlang.org/show_bug.cgi?id=18811 Richard Cattermolechanged: What|Removed |Added CC||alphaglosi...@gmail.com --
[Issue 18811] New: root/array.d leaks
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
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
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
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
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. --