[Issue 14476] New: core.thread unit tests failing on FreeBSD 9+
https://issues.dlang.org/show_bug.cgi?id=14476
Issue ID: 14476
Summary: core.thread unit tests failing on FreeBSD 9+
Product: D
Version: unspecified
Hardware: All
OS: FreeBSD
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
I am consistently seeing this when I try and run druntime's unit tests on
FreeBSD for either 2.067 or master (2.068 alpha):
0.000s PASS release64 object
0.000s PASS release64 core.atomic
0.008s PASS release64 core.bitop
0.000s PASS release64 core.checkedint
0.000s PASS release64 core.demangle
0.000s PASS release64 core.exception
0.000s PASS release64 core.math
0.000s PASS release64 core.memory
posix.mak:230: recipe for target 'obj/64/core/thread' failed
gmake: *** [obj/64/core/thread] Illegal instruction
gmake: *** Deleting file 'obj/64/core/thread'
The druntime unit tests for 2.066 run just fine, so whatever the problem is was
either introduced in 2.067, or a new test that triggers it was introduced.
I'm running the latest PC-BSD on x86_64 (so FreeBSD 10.1), and someone else in
the newsgroup sees the same thing on their 9.1 i386 machine:
http://forum.dlang.org/post/koxlbjptuyccdygvk...@forum.dlang.org
The autotester is not hitting this problem, so clearly, it doesn't exist on all
FreeBSD systems However, apparently, the autotester is currently running
FreeBSD 8.4, so that would imply that the problem only exists in FreeBSD 9+. I
narrowed it down to the last test in core.thread:
unittest
{
auto thr = new Thread(function{}, 10).start();
thr.join();
}
And if I remove the , 10 from the constructor call, then it works - but then
the druntime unit test build fails later:
Testing link
Testing load
Testing linkD
Testing linkDR
Testing loadDR
Testing host
Testing finalize
Testing link_linkdep
Makefile:28: recipe for target 'obj/freebsd/64/link_linkdep.done' failed
gmake[1]: *** [obj/freebsd/64/link_linkdep.done] Segmentation fault
gmake[1]: Leaving directory
'/usr/home/jmdavis/Programming/github/druntime/test/shared'
posix.mak:242: recipe for target 'test/shared/.run' failed
gmake: *** [test/shared/.run] Error 2
I have no idea if it's a related problem or not, but if it isn't, then another
problem was introduced in 2.067 which only exists on FreeBSD 9+. But
regardless, something about setting the stack size for threads isn't working
properly on FreeBSD 9+.
--
[Issue 8207] OS X: Should extern(D) symbols include another underscore?
https://issues.dlang.org/show_bug.cgi?id=8207 Dan Olson go...@comcast.net changed: What|Removed |Added CC||go...@comcast.net --- Comment #2 from Dan Olson go...@comcast.net --- I would think yes, D symbols emitted to the object file on OS X should have extra underscore. And .mangleof should produce the symbol without the extra underscore as it does today. extern(C++) has opposite problem. The extra underscore is present in object file (correct) but is also present in .mangleof symbol. It should be stripped from the .mangleof symbol. Note: ldc merge-2.067 does this now which caused test compilable/test7030.d to fail, which is how I got here. I think LDC is correct. -- demo -- void dfun(int); extern(C++) void cxxfun(int); extern (C) void cfun(int); pragma(msg, dfun.mangleof); pragma(msg, cxxfun.mangleof); pragma(msg, cfun.mangleof); dmd 2.067 produces: _D10showmangle4dfunFiZv __Z6cxxfuni cfun where obj file has these symbols: U _D10showmangle4dfunFiZv U __Z6cxxfuni U _cfun --
[Issue 14079] Variable templates' documentation not generated.
https://issues.dlang.org/show_bug.cgi?id=14079 Gary Willoughby d...@nomad.so changed: What|Removed |Added Keywords||pull CC||d...@nomad.so --- Comment #1 from Gary Willoughby d...@nomad.so --- https://github.com/D-Programming-Language/phobos/pull/3212 --
[Issue 14469] file.readText on Win64 doesn't work for files 4GB.
https://issues.dlang.org/show_bug.cgi?id=14469
--- Comment #1 from Kenny Alive artemal...@gmail.com ---
Additionally since ReadFile (and ReadFileEx too) can read file in chunks not
larger than 4GB the file reading code should be updated to something like this:
ulong totalNumRead = 0;
while (totalNumRead != size)
{
uint chunkSize = (size - totalNumRead) 0x;
DWORD numRead = void;
cenforce(ReadFile(hFile, cast(ubyte*)lpBuffer + totalNumRead,
chunkSize, numRead, null) != 0
numRead == chunkSize, name);
totalNumRead += chunkSize;
}
--
[Issue 6032] wstring literals cannot be implicitly converted to const(wchar)*
https://issues.dlang.org/show_bug.cgi?id=6032 Elie Morisse syniu...@gmail.com changed: What|Removed |Added CC||syniu...@gmail.com --- Comment #3 from Elie Morisse syniu...@gmail.com --- const(char)* s = fooc; // fails too Any rationale behind this? --
[Issue 14478] New: isInputRange failed to recognize some ranges
https://issues.dlang.org/show_bug.cgi?id=14478
Issue ID: 14478
Summary: isInputRange failed to recognize some ranges
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: ket...@ketmar.no-ip.org
assume we have this code:
import std.range;
import std.stdio;
struct S {
int n;
@disable this (this);
}
void main () {
S[2] s0, s1;
foreach (ref el; chain(s0[], s1[])) writeln(el.n);
}
if we try to compile it, we got error:
(12): Error: template std.range.chain cannot deduce function from argument
types
yet if we will remove `@disable this (this);`, everything is working fine.
the bug is in `isInputRange` template:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range (HERE!)
}));
}
line `auto h = r.front;` causes the bug. althru `front` returning ref here, we
can't declare ref variables, so `h` looses `ref` and thus requires copying. yet
we explicitly disabled copying for our struct, so `isInputRange` is failing.
here is the proposed fix:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
static void testfront(T) (auto ref T n) {} testfront(r.front);
}));
}
here we using nested function with `auto ref` to not loose `ref` from `front`.
it would be good to check if some other templates requires such fix too.
p.s. with the proposed fix sample code works like a charm.
--
[Issue 14477] New: Nullable does not work with structs with default constructor disabled
https://issues.dlang.org/show_bug.cgi?id=14477
Issue ID: 14477
Summary: Nullable does not work with structs with default
constructor disabled
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: jus...@economicmodeling.com
The following simple code does not compile:
--
import std.typecons;
struct Foo
{
int x;
@disable this();
this(int value) { x=value; }
}
void main()
{
Nullable!Foo foo;
}
--
test.d(14): Error: variable test.main.foo default construction is disabled for
type Nullable!(Foo)
Of course, one of the major use-cases for Nullable is to provide a way to
default-initialize such a struct to a null state.
--
[Issue 14478] isInputRange failed to recognize some ranges
https://issues.dlang.org/show_bug.cgi?id=14478 --- Comment #1 from Ketmar Dark ket...@ketmar.no-ip.org --- seems that `isBidirectionalRange` can be affected too. --
[Issue 14477] Nullable does not work with structs with default constructor disabled
https://issues.dlang.org/show_bug.cgi?id=14477 Justin Whear jus...@economicmodeling.com changed: What|Removed |Added Keywords||pull Status|NEW |ASSIGNED URL||https://github.com/D-Progra ||mming-Language/phobos/pull/ ||3213 --
[Issue 14080] No mention of documented unittests on ddoc's page
https://issues.dlang.org/show_bug.cgi?id=14080 --- Comment #4 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/738506db345b483657cd11c63ad49ba1b566d5a5 Fix issue 14080 https://github.com/D-Programming-Language/dlang.org/commit/98c8d8146dac68a2fdd2d04a9596011c2ef7d187 Merge pull request #971 from nomad-software/issue_14080 Issue 14080 - No mention of documented unittests on ddoc's page --
[Issue 12920] ICE: Internal error: backend/symbol.c 1035
https://issues.dlang.org/show_bug.cgi?id=12920 --- Comment #3 from Marc Schütz schue...@gmx.net --- Is it really a duplicate? The code in the other bug is clearly invalid, but this one should work IMO. --
[Issue 14476] core.thread unit tests failing on FreeBSD 9+
https://issues.dlang.org/show_bug.cgi?id=14476 --- Comment #1 from Joakim db...@joakim.fea.st --- I can confirm that that last unittest is the one causing the problem on i386 also, as commenting it out gets core.thread to pass and the tests to fail here instead: Testing link Testing load Testing linkD Testing linkDR Testing loadDR Testing host gmake[1]: *** [obj/freebsd/32/host.done] Segmentation fault: 11 (core dumped) This is with dmd/druntime HEAD on FreeBSD 9.1 stable from a couple years ago running in a VM. --
[Issue 14468] [Reg 2.068.0-devel] overload mismatch for template instance with typesafe variadic parameter
https://issues.dlang.org/show_bug.cgi?id=14468 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #3 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4603 --
[Issue 12920] ICE: Internal error: backend/symbol.c 1035
https://issues.dlang.org/show_bug.cgi?id=12920 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz Hardware|x86_64 |All OS|Linux |All --- Comment #4 from Martin Krejcirik m...@krej.cz --- (In reply to Marc Schütz from comment #3) Is it really a duplicate? The code in the other bug is clearly invalid, but this one should work IMO. In this example 'v' is a runtime variable and as such it cannot be a case variable. If a,b,c were enums, it would compile. But I don't understand why uint a,b,c gives error message Error: variable v cannot be read at compile time but int a,b,c does not. So maybe it's a different bug. --
[Issue 14048] std.container documentation issues
https://issues.dlang.org/show_bug.cgi?id=14048 Gary Willoughby d...@nomad.so changed: What|Removed |Added CC||d...@nomad.so --- Comment #1 from Gary Willoughby d...@nomad.so --- This looks like this has been fixed. --
[Issue 14048] std.container documentation issues
https://issues.dlang.org/show_bug.cgi?id=14048 grogan.co...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from grogan.co...@gmail.com --- Yep, it has! --
[Issue 7392] ICE(symbol.c) on invalid nested case statement
https://issues.dlang.org/show_bug.cgi?id=7392 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz --
[Issue 14479] isInputRange returns false on a slice of noncopyables.
https://issues.dlang.org/show_bug.cgi?id=14479 Brian Smith block8...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Brian Smith block8...@gmail.com --- *** This issue has been marked as a duplicate of issue 14478 *** --
[Issue 14478] isInputRange failed to recognize some ranges
https://issues.dlang.org/show_bug.cgi?id=14478 Brian Smith block8...@gmail.com changed: What|Removed |Added CC||block8...@gmail.com --- Comment #2 from Brian Smith block8...@gmail.com --- *** Issue 14479 has been marked as a duplicate of this issue. *** --
[Issue 14006] Contribute button/option on the main site and sitemap
https://issues.dlang.org/show_bug.cgi?id=14006 Gary Willoughby d...@nomad.so changed: What|Removed |Added Keywords||pull CC||d...@nomad.so --- Comment #1 from Gary Willoughby d...@nomad.so --- https://github.com/D-Programming-Language/dlang.org/pull/972 --
[Issue 14468] [Reg 2.068.0-devel] overload mismatch for template instance with typesafe variadic parameter
https://issues.dlang.org/show_bug.cgi?id=14468 --- 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/9c728ce3a8757050cc50407df34eb3f4d0bbceed fix Issue 14468 - overload mismatch for template instance with typesafe variadic parameter https://github.com/D-Programming-Language/dmd/commit/2c102ce5d55cea1259a27e3e32c850cc39f53d6b Merge pull request #4603 from 9rnsr/fix14468 [REG2.068a] Issue 14468 - overload mismatch for template instance with typesafe variadic parameter --
[Issue 14468] [Reg 2.068.0-devel] overload mismatch for template instance with typesafe variadic parameter
https://issues.dlang.org/show_bug.cgi?id=14468 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14183] Updates to groupBy
https://issues.dlang.org/show_bug.cgi?id=14183 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/afd30b41b09b9298f56ccba19068f1fbcab6fbb5 Merge pull request #3005 from Poita/Issue14183 Fix Issue 14183 - Changes to groupBy --
[Issue 14385] AA should use open addressing hash
https://issues.dlang.org/show_bug.cgi?id=14385 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to open_addressing at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/79bc91b41334c1805f557ef2f1606de31c6764d1 fix Issue 14385 - AA should use open addressing hash - new AA implementation - uses open addressing with quadratic probing (triangular numbers) and pow2 table - uses NO_SCAN for entries when applicable - minimizes alignment gap for values - calls postblit on aa.keys and aa.values --
[Issue 14385] AA should use open addressing hash
https://issues.dlang.org/show_bug.cgi?id=14385 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14385] AA should use open addressing hash
https://issues.dlang.org/show_bug.cgi?id=14385 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||schvei...@yahoo.com Resolution|FIXED |--- --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com --- Not sure how that happened, I think possibly Martin pushed to the main repo with his branch by accident. Since deleted. --
[Issue 6032] wstring literals cannot be implicitly converted to const(wchar)*
https://issues.dlang.org/show_bug.cgi?id=6032 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #4 from yebblies yebbl...@gmail.com --- (In reply to Elie Morisse from comment #3) const(char)* s = fooc; // fails too Any rationale behind this? Essentially that 'c' gives it an explicit type, so conversions are disabled. --
[Issue 14463] [REG2.067] DMD crashes compiling module level immutable struct that takes an array in ctor
https://issues.dlang.org/show_bug.cgi?id=14463 --- 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/20f0f7c3ad6a78c668dbc7f8dfd644bc39c7fd0b fix Issue 14463 - [REG2.067] DMD crashes compiling module level immutable struct that takes an array in ctor https://github.com/D-Programming-Language/dmd/commit/d55f2cf7a66744b5c1d5db3f9861a8c5af260368 Merge pull request #4604 from 9rnsr/fix14463 [REG2.067] Issue 14463 - DMD crashes compiling module level immutable struct that takes an array in ctor --
[Issue 14463] [REG2.067] DMD crashes compiling module level immutable struct that takes an array in ctor
https://issues.dlang.org/show_bug.cgi?id=14463 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14478] isInputRange failed to recognize some ranges
https://issues.dlang.org/show_bug.cgi?id=14478 --- Comment #5 from Jonathan M Davis issues.dl...@jmdavisprog.com --- Sure, some may work, but many won't, and a lot of user code out there won't. Grepping for such usage in Phobos quickly finds some, and a function like std.array.array _can't_ work with non-copyable elements (and that's a pretty major range-based function in Phobos). auto h = r.front; has been part of the definition of input ranges from the beginning, and so, everyone has been free to assume that a range's elements are copyable, because the definition of an input range guarantees it. We can't expect that it won't break code to change that now - especially when having non-copyable elements is so rare. This is the first time that I've ever heard anyone complain about this issue, so it clearly isn't affecting very many people, and the C++ folks thought that it was okay to require that elements in STL containers be copyable, so we're not the first to require that sort of thing with a major component of the standard library. I can see why you'd want to able to have ranges work with non-copyable elements, but simply changing the definition of an input range would break too much code, and I think that it's naive to expect that most range-based code would work with the change. I've seen plenty of cases in code where something like auto value = range.front; is done, and if this change were made, then that code's template constraints would be claiming that it worked with non-copyable elements when it didn't, and as it is now, such template constraints actually guarantee that non-copyable elements aren't used with such algorithms. If we were going to support anything like this, then we'd need a new set of traits for it rather than simply changing isInputRange, and given how rare this use case is, I don't think that it's worth it. I'd suggest that you just wrap a would-be range with non-copyable elements in another range which makes it so that they _are_ copyable (e.g. via pointer) and get around the problem that way. --
[Issue 14478] isInputRange failed to recognize some ranges
https://issues.dlang.org/show_bug.cgi?id=14478 --- Comment #4 from Ketmar Dark ket...@ketmar.no-ip.org --- yet at least some std.algorithm algorithms are able to work with such ranges. chain works ok, filter works too. others will do too, i think, with `(ref a)` predicates. yet current implementation forbids such usage. --
[Issue 14474] Use UTF-8 encoding for @cmdfile
https://issues.dlang.org/show_bug.cgi?id=14474 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #2 from Martin Nowak c...@dawg.eu --- (In reply to Dāvis from comment #0) One solution could be to change DUB to save it in Windows default ANSI code page, but I think that's a very bad idea because then that file won't be portable. It doesn't need to be portable, it's just used for a single compiler invocation. So best would be to enforce it being in UTF-8 encoding and then decode in DMD for respective code page which is used for WinAPI calls. UTF-8 sounds reasonable. --
[Issue 14478] isInputRange failed to recognize some ranges
https://issues.dlang.org/show_bug.cgi?id=14478 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #3 from Jonathan M Davis issues.dl...@jmdavisprog.com --- If auto h = r.front; doesn't work, then I don't think that it can be a range. And if that means that elements have to be copyable to be in a range, then I think that they're going to have to be copyable. There is going to be _way_ too much code out there that does auto h = r.front; for it to work to try and claim that something is an input range when that line doesn't work. And IIRC, C++ STL containers require that their elements be copyable in order to work, so it's not like we'd be the first to require this sort of thing. --
[Issue 14463] [REG2.067] DMD crashes compiling module level immutable struct that takes an array in ctor
https://issues.dlang.org/show_bug.cgi?id=14463 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||CTFE, ice, pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4604 --
[Issue 14119] Must not allocate TraceInfo for FinalizeErrors
https://issues.dlang.org/show_bug.cgi?id=14119 --- Comment #2 from Martin Nowak c...@dawg.eu --- We should require http://dlang.org/library/core/runtime/runtime.trace_handler.html to be @nogc. For a deprecation phase we could still accept allocating trace handlers, but not call them in @nogc errors like onOutOfMemoryError. --
[Issue 14080] No mention of documented unittests on ddoc's page
https://issues.dlang.org/show_bug.cgi?id=14080 Gary Willoughby d...@nomad.so changed: What|Removed |Added Keywords||pull CC||d...@nomad.so --- Comment #3 from Gary Willoughby d...@nomad.so --- https://github.com/D-Programming-Language/dlang.org/pull/971 --
[Issue 943] DDoc ignoring sections, not making paragraphs
https://issues.dlang.org/show_bug.cgi?id=943 David Eagen da...@eagen.com changed: What|Removed |Added CC||da...@eagen.com --- Comment #1 from David Eagen da...@eagen.com --- Tested on 2.067.0 Linux amd64 and both the History and Copyright work according to the DDoc documentation. --
[Issue 943] DDoc ignoring sections, not making paragraphs
https://issues.dlang.org/show_bug.cgi?id=943 David Eagen da...@eagen.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from David Eagen da...@eagen.com --- Tested in DMD 1.076 and both Copyright and History function there as well. Closing as works for me. --
[Issue 14479] New: isInputRange returns false on a slice of noncopyables.
https://issues.dlang.org/show_bug.cgi?id=14479
Issue ID: 14479
Summary: isInputRange returns false on a slice of noncopyables.
Product: D
Version: unspecified
Hardware: x86_64
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: block8...@gmail.com
Example: http://dpaste.dzfl.pl/644619159a4f
import std.range, std.stdio;
struct Noncopyable {
int num;
@disable this(this);
}
void main() {
writeln(isInputRange!(Noncopyable[]));
}
It is believed that this problem is caused by r.front needing to return a value
instead of a reference, in contradiction of the docs, which say r.front
returns the current element in the range. It may return by value or by
reference.
This prevents using range utility functions like chain() on arrays of
noncopyables, such as in http://dpaste.dzfl.pl/3993a52c54df .
--
[Issue 150] (D1 only) std.gc.minimize doesn't minimize physical memory usage
https://issues.dlang.org/show_bug.cgi?id=150 David Eagen da...@eagen.com changed: What|Removed |Added CC||da...@eagen.com Summary|std.gc.minimize doesn't |(D1 only) std.gc.minimize |minimize physical memory|doesn't minimize physical |usage |memory usage --
[Issue 387] When EOF of din is reached, a line of output is lost
https://issues.dlang.org/show_bug.cgi?id=387 David Eagen da...@eagen.com changed: What|Removed |Added Status|NEW |RESOLVED CC||da...@eagen.com Resolution|--- |INVALID --- Comment #12 from David Eagen da...@eagen.com --- Closing as invalid as the problem appears to be caused by an OS bug in versions of Windows that are no longer supported. --
