Bug 9598 – Cannot use moveFront on MapResult!(lambda, ByLine!(char, char))

Status
RESOLVED
Resolution
WORKSFORME
Severity
major
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
Windows
Creation time
2013-02-26T22:33:51Z
Last change time
2018-10-16T18:24:11Z
Assigned to
No Owner
Creator
Chris Cain

Comments

Comment #0 by zshazz — 2013-02-26T22:33:51Z
Using DMD 2.062 with no command line arguments other than the source file in question I have the following (expected valid) code: --- import std.stdio, std.file, std.algorithm, std.conv, std.range; void main() { dirEntries("data", "*.out", SpanMode.shallow) .map!(e => File(e.name).byLine() .map!(line => text(line))() // compile error )() .array() .nWayUnion() // line 9 .copy(stdout.lockingTextWriter); } --- Which produces errors. Error 1 is a compile-time failure producing the following message: --- C:\D\dmd2\windows\bin\..\..\src\phobos\std\range.d(6695): Error: static assert "Cannot move front of a range with a postblit and an rvalue front." C:\D\dmd2\windows\bin\..\..\src\phobos\std\container.d(3797): instantiated from here: moveFront!(MapResult!(__lambda4, ByLine!(char, char))[]) C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(10526): instantiated from here: BinaryHeap!(MapResult!(__lambda4, ByLine!(char, char))[], compFront) C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(10562): instantiated from here: NWayUnion!("a < b", MapResult!(__lambda4, ByLine!(char, char))[]) D:\[snip]\src\reducedCase.d(9): instantiated from here: nWayUnion!("a < b", MapResult!(__lambda4, ByLine!(char, char))[]) --- If I change the code to this: --- import std.stdio, std.file, std.algorithm, std.conv, std.range; void main() { dirEntries("data", "*.out", SpanMode.shallow) .map!(e => File(e.name).byLine() .map!text() // Compiles, runtime error )() .array() .nWayUnion() // line 9 .copy(stdout.lockingTextWriter); } --- Then the code compiles, but produces a runtime error (when files are in data directory and named *.out): object.Error: Access Violation ---------------- 0x00429674 0x004294FF 0x7730B459 in LdrRemoveLoadAsDataTable 0x7730B42B in LdrRemoveLoadAsDataTable 0x772C0133 in KiUserExceptionDispatcher 0x0018F6E8 0x0018F738 ---------------- Specifically, these errors apply to MapResult!(lambda, ByLine!(char, char)). For instance, using a string[][] as an array and applying a .map!text() as above, there is no problem for either case. --- import std.stdio, std.file, std.algorithm, std.conv, std.range; void main() { [["abc", "cbd"], ["dce", "efg"]] .map!(e => //e.map!text() // OK e.map!(line => text(line))() // OK )() .array() .nWayUnion() .copy(stdout.lockingTextWriter); } ---
Comment #1 by maxim — 2013-02-27T04:49:11Z
Can confirm on linux. What's interesting is that executable crashes during garbage collection which I haven't met before.
Comment #2 by bearophile_hugs — 2013-02-27T05:02:04Z
(In reply to comment #0) > Then the code compiles, but produces a runtime error (when files are in data > directory and named *.out): > > object.Error: Access Violation > ---------------- > 0x00429674 > 0x004294FF > 0x7730B459 in LdrRemoveLoadAsDataTable > 0x7730B42B in LdrRemoveLoadAsDataTable > 0x772C0133 in KiUserExceptionDispatcher > 0x0018F6E8 > 0x0018F738 > ---------------- In such cases it's better to _also_ compile with -g, that shows an error in void* gc.gcx.GC.mallocNoSync(uint, uint, uint*).
Comment #3 by zshazz — 2013-02-27T05:13:20Z
(In reply to comment #2) > In such cases it's better to _also_ compile with -g, that shows an error in > void* gc.gcx.GC.mallocNoSync(uint, uint, uint*). Good point, thanks for the information. Here's what it's giving me on my system (running Windows 7 64-bit): object.Error: Access Violation ---------------- 0x0042C7C4 in char[][] core.sys.windows.stacktrace.StackTrace.trace() 0x0042C64F in core.sys.windows.stacktrace.StackTrace core.sys.windows.stacktrace .StackTrace.__ctor() 0x7730B459 in LdrRemoveLoadAsDataTable 0x7730B42B in LdrRemoveLoadAsDataTable 0x772C0133 in KiUserExceptionDispatcher 0x002B1ECB ----------------
Comment #4 by safety0ff.bugz — 2013-10-25T13:48:08Z
The access violation case seems to have been fixed sometime between 2.063.2 and current git version.