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.