[Issue 8786] New: assert does not call invariant() function
http://d.puremagic.com/issues/show_bug.cgi?id=8786
Summary: assert does not call invariant() function
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-10-09 01:19:41 PDT ---
According to http://dlang.org/class.html#Invariant
The invariant can be checked when a class object is the argument to an
assert() expression, as:
//
Date mydate;
...
assert(mydate); // check that class Date invariant holds
//
But I get:
//
struct S
{
invariant(){}
}
void main()
{
S s;
assert(s);
}
//
Error: expression s of type S does not have a boolean value
//
IMO, behavior of assert should be:
1. Check for argument can be cast to bool. If yes, do it. The call should
trigger invariant check anyways.
2. Else, call invariant directly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8786] assert does not call invariant() function
http://d.puremagic.com/issues/show_bug.cgi?id=8786 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2012-10-09 01:44:22 PDT --- This was discussed a lot... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8787] New: Virtual not abstract methods in interfaces error message
http://d.puremagic.com/issues/show_bug.cgi?id=8787
Summary: Virtual not abstract methods in interfaces error
message
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-10-09 01:45:24 PDT ---
interface Foo {
void bar() {}
}
void main() {}
DMD 2.061alpha gives:
temp.d(2): Error: function temp.Foo.bar function body is not abstract in
interface Foo
But I suggest an error message like this because final methods are allowed in
D2 interfaces:
temp.d(2): Error: function temp.Foo.bar function body is not abstract or final
in interface Foo
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8786] assert does not call invariant() function
http://d.puremagic.com/issues/show_bug.cgi?id=8786 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 01:52:20 PDT --- Yes, _class_ object's have their invariant called. You're using a struct. It's cast to bool (like it would be in the condition of an if statement), and your struct doesn't define a cast to bool, so it doesn't work. If you want to check the invariant, then take its address so that you're operating on a pointer to a struct. In that case, it will act the same way that a class does. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8784] std.bigint.BigInt.infinity
http://d.puremagic.com/issues/show_bug.cgi?id=8784 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||INVALID --- Comment #1 from Don clugd...@yahoo.com.au 2012-10-09 03:09:45 PDT --- For floating point numbers of limited size, you need infinity for overflow, and you can possibly also follow IEEE in generating it for division by zero. It's more a necessary evil than a desirable feature. But for BigInt it is quite different. There is no BigInt operation which results in an overflow, and division by zero is an error. And infinity is a really, really annoying special case, both in terms of implementation (where it has a performance penalty) and from the user's side. You have to sacrifice some important guarantees, eg assert(x + 1 != x); is not always true for any type which includes infinity. That sacrifice doesn't happen for IEEE floating point, since already x + 1 == x for any large number such as real.max / 2, due to reduced precision. But for BigInt, it's a huge price to pay. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8784] std.bigint.BigInt.infinity
http://d.puremagic.com/issues/show_bug.cgi?id=8784 --- Comment #2 from bearophile_h...@eml.cc 2012-10-09 04:00:17 PDT --- (In reply to comment #1) But for BigInt, it's a huge price to pay. OK. I have templated code that works with integral types, and uses T.max (or T.infinty if T is a floating point). To make it work with bigints I have to use a huge_bigint_val or to change the code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8784] std.bigint.BigInt.infinity
http://d.puremagic.com/issues/show_bug.cgi?id=8784 --- Comment #3 from Don clugd...@yahoo.com.au 2012-10-09 05:01:47 PDT --- (In reply to comment #2) (In reply to comment #1) But for BigInt, it's a huge price to pay. OK. I have templated code that works with integral types, and uses T.max (or T.infinty if T is a floating point). To make it work with bigints I have to use a huge_bigint_val or to change the code. I think it's reasonable to have to change the code. Whenever you use T.max, you are explicitly using a type with finite representation size. Floating point has both a T.max and a T.infinity, both of which have different semantics to integer.max. Actually I find it difficult to think of non-trivial algorithms which work correctly even just for built-in integers and built-in floating point. There isn't much common semantics. Eg, even sum() needs special treatment. sum([real.max, real.max, -real.max, -real.max, 7.0]) == 7.0, not infinity or NaN. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8788] New: The super constructor call can be prevented by mentioning return.
http://d.puremagic.com/issues/show_bug.cgi?id=8788
Summary: The super constructor call can be prevented by
mentioning return.
Product: D
Version: D1 D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: david.ecka...@sociomantic.com
--- Comment #0 from David Eckardt david.ecka...@sociomantic.com 2012-10-09
07:20:46 PDT ---
Mentioning a return prevents DMD from rejecting code where a constructor has
an explicit super() call which is done conditionally or not at all. Also it is
possible to return or throw before doing the super() call.
This example code compiles although it should be rejected:
---
class A { this ( ) { } }
class B : A
{
this ( )
{
return;
super();
}
this(int x)
{
try
{
throw new Exception;
super();
}
catch ( ) { }
}
this(float f)
{
if (x == 3)
return;
else
super();
}
this(char c)
{
if (c == 'x')
super();
else
return;
}
}
---
However, if the return statement in the second and third constructor is
omitted, the compile error is triggered correctly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8788] The super constructor call can be prevented by mentioning return.
http://d.puremagic.com/issues/show_bug.cgi?id=8788 --- Comment #1 from David Eckardt david.ecka...@sociomantic.com 2012-10-09 07:27:39 PDT --- Of course the if condition in the third constructor should be f = 3, not x == 3. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8789] New: mangling of const member function
http://d.puremagic.com/issues/show_bug.cgi?id=8789
Summary: mangling of const member function
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO zan77...@nifty.com 2012-10-09 07:32:24 PDT ---
Document of mangling for const member function is not completed.
Now, TypeFunction of ABI doesn't consider the const/immutable/shared/inout
attributes.
TypeFunction:
CallConvention FuncAttrs Arguments ArgClose Type
These mangling schemes don't include const/immutable/shared/inout attributes.
If const/immutable/shared/inout attributes are contained in FuncAttrs,
following mangling is wrong:
---
class A
{
void func() const {}
}
pragma(msg, typeof(A.func).mangleof); // xFZv
---
typeof(A.func).mangleof must be FxZv
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8751] Problem with pure inference of inner delegate
http://d.puremagic.com/issues/show_bug.cgi?id=8751 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #5 from yebblies yebbl...@gmail.com 2012-10-10 02:32:00 EST --- https://github.com/D-Programming-Language/dmd/commit/6ecd4f3c9c062d2c297b3dde2f7286314607aa1c -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8644] CTFE doesn't support string , on array literals
http://d.puremagic.com/issues/show_bug.cgi?id=8644 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Version|D1 D2 |D1 --- Comment #2 from yebblies yebbl...@gmail.com 2012-10-10 02:35:38 EST --- Fix for D2: https://github.com/donc/dmd/commit/8cd8f05dfe1caa050c2995b410d7e73b696cb6ad -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8644] CTFE doesn't support string , on array literals
http://d.puremagic.com/issues/show_bug.cgi?id=8644 --- Comment #3 from github-bugzi...@puremagic.com 2012-10-09 09:12:57 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8cd8f05dfe1caa050c2995b410d7e73b696cb6ad Fix bug 8644 - CTFE doesn't support string , on array literals https://github.com/D-Programming-Language/dmd/commit/f3ee71f1f422fd0ee8863109469f4065a8305b5f Merge pull request #1114 from donc/ctfe8644_arrayliteralcmp Fix bug 8644 - CTFE doesn't support string , on array literals -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8644] CTFE doesn't support string , on array literals
http://d.puremagic.com/issues/show_bug.cgi?id=8644 --- Comment #4 from yebblies yebbl...@gmail.com 2012-10-10 03:15:10 EST --- Whoops. This is the merge commit. https://github.com/D-Programming-Language/dmd/commit/f3ee71f1f422fd0ee8863109469f4065a8305b5f -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8751] Problem with pure inference of inner delegate
http://d.puremagic.com/issues/show_bug.cgi?id=8751
--- Comment #6 from bearophile_h...@eml.cc 2012-10-09 10:04:36 PDT ---
This code, that is derived more closely from my use case, gives an error, after
merging the patch:
alias bool delegate(in int) pure Dg;
Dg foo1(immutable Dg f) pure {
return x = f(x); // OK
}
Dg foo2(const Dg f) pure {
return x = f(x); // error
}
void main() {}
DMD patched gives:
temp.d(6): Error: cannot implicitly convert expression (__lambda4) of type bool
delegate(const(int) x) @system to bool delegate(const(int)) pure
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8786] assert does not call invariant() function
http://d.puremagic.com/issues/show_bug.cgi?id=8786 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 10:50:32 PDT --- The behavior of classes was discussed a lot (in particular, it didn't use to check whether the reference was null first, which caused a lot of problems). I'm not sure that the behavior of structs has been discussed much or that it is necessarily entirely desirable (it's certainly not well-documented), but that's how it works right now. Certainly, it makes perfect sense that the struct would be converted to bool. Whether it should also have its invariant called is debatable, but as long as the conversion to bool involves calling a public member function, the invariant will be called anyway. So, the behavior is probably fine. The fact that the invariant is explicitly checked with a pointer to a struct is then essentially the same as what happens with classes, so really, the way that structs currently work with assert is probably the best way to go about it. The main problem is that it's not necessarily intuitive and that it's not properly documented. So, if the docs are updated, then it should be fine. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8644] CTFE doesn't support string , on array literals
http://d.puremagic.com/issues/show_bug.cgi?id=8644 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Version|D1 |D1 D2 Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7772] Remove volatile statements from core.thread
http://d.puremagic.com/issues/show_bug.cgi?id=7772 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:00:57 CEST --- This now done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7772] Remove volatile statements from core.thread
http://d.puremagic.com/issues/show_bug.cgi?id=7772 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-09 17:05:28 PDT --- Thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8790] New: Compiling with optimization produces erroneous variable initialization error
http://d.puremagic.com/issues/show_bug.cgi?id=8790
Summary: Compiling with optimization produces erroneous
variable initialization error
Product: D
Version: D2
Platform: All
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2012-10-09 17:41:02 PDT ---
import std.algorithm;
import std.range;
void main() {
auto N2 = sequence!n(cast(size_t)1).map!a;
}
When compiling with dmd -O (latest git for dmd, druntime, phobos), this
produces the following errors:
/usr/src/d/phobos/std/range.d(4590): Error: variable upper used before set
/usr/src/d/phobos/std/range.d(4590): Error: variable lower used before set
The referenced line of code occurs in this context:
auto opSlice(size_t lower, size_t upper)
in
{
assert(upper = lower); // this is line 4590
}
body
{
auto s = typeof(this)(this._state, this._n + lower);
return takeExactly(s, upper - lower);
}
Which makes no sense, because there is nothing wrong with the reference to
upper and lower (they are function parameters). Perhaps the optimizer
inadvertently permuted the order of stuff in a way that caused the contract to
run before the parameters are initialized?
If -O is not specified, the compile is successful. This problem appears to be
independent of whether I specify -m32 or -m64.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2563] Derived class is implicitly castable to Base class when inherited privately
http://d.puremagic.com/issues/show_bug.cgi?id=2563 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||WONTFIX --- Comment #9 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:41:02 CEST --- Considering D1 is close to being discontinued and this feature is long deprecated in D2, I think it's safe to close this. I don't see anyone ever getting around to fixing it, so keeping it open is somewhat pointless. (Feel free to reopen if you disagree.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1335] typedef-1 can't be stored in same typedef
http://d.puremagic.com/issues/show_bug.cgi?id=1335 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||WONTFIX --- Comment #7 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:42:06 CEST --- Closing since typedef is effectively deprecated. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8791] New: Optlink fails when reading PATH variable and -g is used
http://d.puremagic.com/issues/show_bug.cgi?id=8791
Summary: Optlink fails when reading PATH variable and -g is
used
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P2
Component: Optlink
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-09
17:42:15 PDT ---
Minimal test-case on WinXP:
test.d:
void main() { }
$ set PATH=D:\DMD\dmd2\windows\bin;C:\Fake+-Dir
$ dmd -g test.d
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Error 118: Filename Expected
Path=D:\DMD\dmd2\windows\bin;C:\Fake+-Dir
^
--- errorlevel 1
GTK3 by default installs to C:\Program Files\GTK+-Bundle-3.4.2\bin, which
breaks Optlink when compiling with -g.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:46:53 CEST --- OK, I think this can be implemented as a library trait. Anyone want to send a pull request that adds it to std.traits? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6909] incorrect definition of the OVERLAPPED struct in core.sys.windows.windows ?
http://d.puremagic.com/issues/show_bug.cgi?id=6909 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #4 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:48:14 CEST --- The definition is correct in druntime now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7112] Add function in core.sys.posix.signal
http://d.puremagic.com/issues/show_bug.cgi?id=7112 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|nob...@puremagic.com|a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:54:59 CEST --- This needs to be added to a separate signalfd header module for Linux only. I'll look into it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5562] Add OS=win32wine build to druntime's posix.mak
http://d.puremagic.com/issues/show_bug.cgi?id=5562 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:14:39 CEST --- Can you provide a patch for this? I imagine porting over the stuff from the Phobos posix.mak shouldn't be too hard, but I don't have a Wine environment to test with. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5593] Add dladdr to druntime for linux/FreeBSD
http://d.puremagic.com/issues/show_bug.cgi?id=5593 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|nob...@puremagic.com|a...@lycus.org -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8791] Optlink fails when reading PATH variable and -g is used
http://d.puremagic.com/issues/show_bug.cgi?id=8791 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-10-09 18:23:02 PDT --- Try enclosing the path in . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5593] Add dladdr to druntime for linux/FreeBSD
http://d.puremagic.com/issues/show_bug.cgi?id=5593 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Keywords||pull --- Comment #3 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:23:07 CEST --- https://github.com/D-Programming-Language/druntime/pull/316 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5589] Incorrect definitions in core.stdc.locale (Windows)
http://d.puremagic.com/issues/show_bug.cgi?id=5589 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:28:26 CEST --- I'm not sure what header you're going by. The MSVC one or the Digital Mars one? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6649] core.sys.posix.sys.ioctl
http://d.puremagic.com/issues/show_bug.cgi?id=6649 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|nob...@puremagic.com|a...@lycus.org -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8418] core.thread.Fiber is a Coroutine or Semi-Coroutine?
http://d.puremagic.com/issues/show_bug.cgi?id=8418 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:34:06 CEST --- Can you please send a pull request with a doc fix? You probably know the API better than I do. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7971] Cannot compile druntime with -debug=PRINTF
http://d.puremagic.com/issues/show_bug.cgi?id=7971 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8273] FreeBSD core.sys.posix.unistd enums severely lacking
http://d.puremagic.com/issues/show_bug.cgi?id=8273 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|nob...@puremagic.com|a...@lycus.org -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3057] Add pure annotations to core.stdc.*
http://d.puremagic.com/issues/show_bug.cgi?id=3057 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #13 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:35:57 CEST --- I sent a pull request a while back that added safety, purity, and nothrow annotations throughout core.stdc (not having noticed the patch here). I'll close this, but if it turns out I forgot some annotations, please reopen. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3696] SuperStack
http://d.puremagic.com/issues/show_bug.cgi?id=3696 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||WONTFIX --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:42:22 CEST --- Let's open an issue if there is actual interest or someone provides a patch. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8633] core.atomic not documented
http://d.puremagic.com/issues/show_bug.cgi?id=8633 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Keywords||pull Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|nob...@puremagic.com|a...@lycus.org --- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:40:03 CEST --- https://github.com/D-Programming-Language/druntime/pull/317 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4332] C files in druntime should be converted to D
http://d.puremagic.com/issues/show_bug.cgi?id=4332 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #16 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:43:03 CEST --- This is now done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4255] Missing declaration on core.stdc.stdio of kbhit function
http://d.puremagic.com/issues/show_bug.cgi?id=4255 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||WONTFIX --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:44:41 CEST --- kbhit by itself is not standardized and _kbhit is apparently ISO C++. core.stdc.* only binds C99. So, closing this... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4222] druntime should apply @safe/@system/@trusted
http://d.puremagic.com/issues/show_bug.cgi?id=4222 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||a...@lycus.org AssignedTo|s...@invisibleduck.org |a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:45:37 CEST --- This is something I'll be working on over the next weeks/months. I have a bit of a monster patch already in-review that needs to be rebased. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4848] core.sys.windows.windows: Environment functions
http://d.puremagic.com/issues/show_bug.cgi?id=4848 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:46:44 CEST --- These are now present. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4862] modfl() missing for FreeBSD
http://d.puremagic.com/issues/show_bug.cgi?id=4862 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:47:40 CEST --- Is this still an issue? And if so, what do we need to do about it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6024] Windows 2000 SP4 is not supported any more? And what is still supported?
http://d.puremagic.com/issues/show_bug.cgi?id=6024 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #19 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:49:22 CEST --- Please submit a pull request to the dpl.org repo so we can get this out of the way. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||WONTFIX --- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:51:55 CEST --- Let us revisit this if it ever becomes a problem in practice; I very much doubt it. At any rate, special-casing it in the GC is the wrong kind of design. I'll also add that I'm against adding GC heap allocation to Variant/Algebraic as this would severely slow down code that uses many instances of these types for no good reason. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5206] stat_t is not the same as struct stat
http://d.puremagic.com/issues/show_bug.cgi?id=5206 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #13 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:52:38 CEST --- Can we close this? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3523] Fiber is not garbage collected properly
http://d.puremagic.com/issues/show_bug.cgi?id=3523 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #12 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:54:02 CEST --- What is the status of this today? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6151] Make the GC functions weakly pure
http://d.puremagic.com/issues/show_bug.cgi?id=6151 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 03:53:28 CEST --- What we really need in order to move forward with this is a way to explicitly tell the compiler that something is weakly pure. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3696] SuperStack
http://d.puremagic.com/issues/show_bug.cgi?id=3696 --- Comment #2 from Chad Joan chadj...@gmail.com 2012-10-09 19:08:23 PDT --- (In reply to comment #1) Let's open an issue if there is actual interest or someone provides a patch. I still want this. I don't know how to implement it efficiently and I haven't used it because it doesn't exist :/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3696] SuperStack
http://d.puremagic.com/issues/show_bug.cgi?id=3696 --- Comment #3 from Alex R�nne Petersen a...@lycus.org 2012-10-10 04:19:20 CEST --- Well, at some point, we have to close enhancement requests because nobody's worked on them. The 'WONTFIX' resolution was not to say it can't/shouldn't be done, but just a reflection of the fact that any core developers are unlikely to work on this (at least right now). By all means, reopen if someone starts work on this. :) (Besides, this should probably be filed against Phobos, not DRuntime.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3696] SuperStack
http://d.puremagic.com/issues/show_bug.cgi?id=3696 --- Comment #4 from Chad Joan chadj...@gmail.com 2012-10-09 19:21:01 PDT --- (In reply to comment #3) Well, at some point, we have to close enhancement requests because nobody's worked on them. The 'WONTFIX' resolution was not to say it can't/shouldn't be done, but just a reflection of the fact that any core developers are unlikely to work on this (at least right now). By all means, reopen if someone starts work on this. :) (Besides, this should probably be filed against Phobos, not DRuntime.) Makes sense. Thank you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8790] Compiling with optimization produces erroneous variable initialization error
http://d.puremagic.com/issues/show_bug.cgi?id=8790 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||DUPLICATE --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 19:22:06 PDT --- I believe that this is a duplicate of bug# 8556. I suspect that at least part of the problem is that takeExactly checks hasSlicing, so if you're using takeExactly to do slicing, it's going to cause problems right now. I'm almost finished on a pull request which will fix that, and that may or may not make it so that this bug doesn't manifest itself with sequence, but if anything, that means that we'd need to find another way to reproduce this bug, because that will just fix the Phobos part, not the compiler bug. *** This issue has been marked as a duplicate of issue 8556 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8556] Using take results in a corrupted call to opSlice
http://d.puremagic.com/issues/show_bug.cgi?id=8556 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 19:22:06 PDT --- *** Issue 8790 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8556] Using take results in a corrupted call to opSlice
http://d.puremagic.com/issues/show_bug.cgi?id=8556
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
Severity|blocker |regression
--- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 19:23:44
PDT ---
I'm changing this to a regression, because bug# 8790 shows an example of where
this causes a regression:
import std.algorithm;
import std.range;
void main() {
auto N2 = sequence!n(cast(size_t)1).map!a;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8730] writeln stops on a nul character, even if passed a D string
http://d.puremagic.com/issues/show_bug.cgi?id=8730 --- Comment #2 from Adam D. Ruppe destructiona...@gmail.com 2012-10-09 19:24:49 PDT --- (In reply to comment #1) The specialization is probably to blame. I think 'args[0].length' probably sets the max limit rather than min, but I don't know enough about fprintf internals. :) Yeah, you're right. The man page for printf says the maximum number of characters to be printed from a string for s and S conversions. I'm not sure what is best here. I really think it should work, but the specialization has got to be there for a reason too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 --- Comment #6 from bearophile_h...@eml.cc 2012-10-09 19:28:00 PDT --- (In reply to comment #5) Let us revisit this if it ever becomes a problem in practice; I very much doubt it. At any rate, special-casing it in the GC is the wrong kind of design. I'll also add that I'm against adding GC heap allocation to Variant/Algebraic as this would severely slow down code that uses many instances of these types for no good reason. I agree that special casing for Algebraic is probably too much. But GC precision is a problem, especially on 32 bit system. And here I was not discussing about allocating an Algebraic on the heap, but the problems caused by putting references to heap-allocated things inside an Algebraic. So it's a problem shared by all unions. The idea of onScan is general, it's not a special case for Algebraic, it's usable to help the GC for all unions (but it's especially useful for Algebraic because it has a tag). Maybe I will open an enhancement request about all unions... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5057] std.variant.Algebraic-aware GC
http://d.puremagic.com/issues/show_bug.cgi?id=5057 --- Comment #7 from Alex R�nne Petersen a...@lycus.org 2012-10-10 04:33:54 CEST --- (In reply to comment #6) (In reply to comment #5) Let us revisit this if it ever becomes a problem in practice; I very much doubt it. At any rate, special-casing it in the GC is the wrong kind of design. I'll also add that I'm against adding GC heap allocation to Variant/Algebraic as this would severely slow down code that uses many instances of these types for no good reason. I agree that special casing for Algebraic is probably too much. But GC precision is a problem, especially on 32 bit system. Absolutely. And here I was not discussing about allocating an Algebraic on the heap, but the problems caused by putting references to heap-allocated things inside an Algebraic. So it's a problem shared by all unions. The idea of onScan is general, it's not a special case for Algebraic, it's usable to help the GC for all unions (but it's especially useful for Algebraic because it has a tag). My comments about heap allocations were not directed at you, but at nfx...@gmail.com. One very trivial way that Algebraic can be made more GC friendly is by making it inspect all types that it can represent - if none of them are references/pointers, signal this to the GC accordingly. It doesn't handle the case where a variant can have both non-GC'd and GC'd types, but I think that this is very rare compared to variants with exclusively GC'd types and variants with exclusively non-GC'd types. Maybe I will open an enhancement request about all unions... I imagine unions in general will be a pain for the new precise GC. But let's wait and see how it handles this problem before we open another issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8730] writeln stops on a nul character, even if passed a D string
http://d.puremagic.com/issues/show_bug.cgi?id=8730 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-10-09 19:38:15 PDT --- (In reply to comment #2) (In reply to comment #1) The specialization is probably to blame. I think 'args[0].length' probably sets the max limit rather than min, but I don't know enough about fprintf internals. :) Yeah, you're right. The man page for printf says the maximum number of characters to be printed from a string for s and S conversions. I'm not sure what is best here. I really think it should work, but the specialization has got to be there for a reason too. It could me off guard just recently. E.g. git uses two strings separated by nul in it's object format, and when I've tried to print out the contents as a char[] using writeln it would only print out a small portion of it, even though printing it as a byte[] would print much more. Anyway this *is* a bug. We can't have it both ways: writeln(bla\0bla); // bla writefln(%s, bla\0bla); // bla[NUL]bla -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6649] core.sys.posix.sys.ioctl
http://d.puremagic.com/issues/show_bug.cgi?id=6649 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Keywords||pull --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-10 04:39:06 CEST --- https://github.com/D-Programming-Language/druntime/pull/318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8792] New: std.algorithm.joiner doesn't return a proper forward range`
http://d.puremagic.com/issues/show_bug.cgi?id=8792
Summary: std.algorithm.joiner doesn't return a proper forward
range`
Product: D
Version: D2
Platform: All
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2012-10-09 20:25:31 PDT ---
import std.algorithm;
import std.range;
import std.stdio;
void main() {
auto x = [[1],[2],[3]];
auto yy = x.joiner;
assert(isForwardRange!(typeof(yy)));
writeln(yy.save);
writeln(yy);
}
The output is:
[]
[1, 2, 3]
Which means that yy.save didn't save at all! This is a pretty major bug since
it makes joiner unusable where the result needs to be a forward range.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8730] writeln stops on a nul character, even if passed a D string
http://d.puremagic.com/issues/show_bug.cgi?id=8730 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #4 from Brad Roberts bra...@puremagic.com 2012-10-09 20:33:42 PDT --- Shouldn't this be trivial to fix: Replace: fprintf(.stdout.p.handle, %.*s\n, cast(int) args[0].length, args[0].ptr) with: fwrite(args[0].ptr, 1, args[0].length, .stdout.p.handle) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8730] writeln stops on a nul character, even if passed a D string
http://d.puremagic.com/issues/show_bug.cgi?id=8730 --- Comment #5 from Brad Roberts bra...@puremagic.com 2012-10-09 20:36:53 PDT --- oops, followed by the same code as in the length == 0 code to get the \n. At which point it's questionable that specialization is all that special. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8556] Using take results in a corrupted call to opSlice
http://d.puremagic.com/issues/show_bug.cgi?id=8556
--- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-10-09 20:52:16
PDT ---
Okay. Here's a test case which does not rely on either take, takeExactly or
hasSlicing (since they will likely be changed soon so that they don't have a
circular dependency, fixing the immediate problem in Phobos but not fixing the
compiler bug):
import std.algorithm;
import std.range;
import std.stdio;
import std.string;
import std.traits;
template isSliceable(R)
{
enum bool isSliceable = !isNarrowString!R is(typeof(
(inout int _dummy=0)
{
R r = void;
auto s = r[1 .. 2];
static assert(isInputRange!(typeof(s)));
}));
}
struct Grab(Range)
if (isInputRange!(Unqual!Range)
!(isSliceable!(Unqual!Range) || is(Range T == Grab!T)))
{
private alias Unqual!Range R;
// User accessible in read and write
public R source;
private size_t _maxAvailable;
private enum bool byRef = is(typeof(_input.front) == ElementType!(R)*);
alias R Source;
@property bool empty()
{
return _maxAvailable == 0 || source.empty;
}
@property auto ref front()
{
assert(!empty,
Attempting to fetch the front of an empty
~ Grab.stringof);
return source.front;
}
void popFront()
{
assert(!empty,
Attempting to popFront() past the end of a
~ Grab.stringof);
source.popFront();
--_maxAvailable;
}
static if (isForwardRange!R)
@property Grab save()
{
return Grab(source.save, _maxAvailable);
}
static if (isInfinite!R)
{
@property size_t length() const
{
return _maxAvailable;
}
alias length opDollar;
}
else static if (hasLength!R)
{
@property size_t length()
{
return min(_maxAvailable, source.length);
}
alias length opDollar;
}
}
Grab!R grab(R)(R input, size_t n)
if (isInputRange!(Unqual!R) isSliceable!(Unqual!R))
{
static if (hasLength!R)
return input[0 .. min(n, input.length)];
else
return input[0 .. n];
}
Grab!(R) grab(R)(R input, size_t n)
if (is(R T == Grab!T))
{
return R(input.source, min(n, input._maxAvailable));
}
Grab!R grab(R)(R input, size_t n)
if (isInputRange!(Unqual!R) !isSliceable!(Unqual!R) !is(R T == Grab!T))
{
return Grab!R(input, n);
}
auto grabExactly(R)(R range, size_t n)
if (isInputRange!R !isSliceable!R)
{
static if (is(typeof(grabExactly(range._input, n)) == R))
{
range._n = n;
return range;
}
else
{
static struct Result
{
R _input;
private size_t _n;
@property bool empty() const { return !_n; }
@property auto ref front()
{
assert(_n 0, front() on an empty ~ Result.stringof);
return _input.front();
}
void popFront() { _input.popFront(); --_n; }
@property size_t length() const { return _n; }
alias length opDollar;
static if (isForwardRange!R)
@property auto save() { return this; }
}
return Result(range, n);
}
}
auto grabExactly(R)(R range, size_t n)
if (isSliceable!R)
{
return range[0 .. n];
}
struct Circle(Range)
if (isForwardRange!(Unqual!Range) !isInfinite!(Unqual!Range))
{
alias Unqual!Range R;
R _original;
size_t _index;
this(R input, size_t index = 0) { _original = input; _index = index; }
@property auto ref front()
{
return _original[_index % _original.length];
}
enum bool empty = false;
void popFront() { ++_index; }
auto opSlice(size_t i, size_t j)
{
assert(j = i, format(%s %s %s, i, j, _index));
writefln(%s %s %s, i, j, _index);
return grabExactly(typeof(this)(_original.save, _index + i), j - i);
}
}
Circle!R circle(R)(R input, size_t index = 0)
if (isRandomAccessRange!(Unqual!R) !isInfinite!(Unqual!R))
{
return Circle!R(input, index);
}
void main()
{
uint[] arr = [1U, 2U, 3U, 4U, 5U, 6U, 7U, 8U, 9U, 10U];
auto t = grab(circle(arr), 20);
auto cx = circle(arr);
auto slice = cx[23 .. 33];
assert(equal(slice, [4, 5, 6, 7, 8, 9, 10, 1, 2, 3]), format(%s,
array(slice)));
}
It can probably be reduced further, but that already reduces it a fair bit.
It's been copied from Phobos with the names being tweaked (hasSlicing -
isSliceable, take - grab, takeExactly - grabExactly) and some of the
unnecessary parts stripped out. So, this should provide a reproducible test
case even once hasSlicing and take have been fixed. I believe that the key
thing is the circular dependencies involved.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7992] std.algorithm.find breaks in certain circumstances
http://d.puremagic.com/issues/show_bug.cgi?id=7992 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx 2012-10-09 20:55:47 PDT --- OK, something is very broken in simpleMindedFind(). When both haystack and needle have the length property, estimateNeedleLength is set to false, and estimatedNeedleLength is set to 0. Therefore, haystackTooShort() is always false. So in the searching loop, the if(haystackTooShort()) is skipped, and it falls straight through to the for(auto h=haystack.save;...) loop. But here, if h.empty is true, then because estimateNeedleLength is false, this goes straight to continue searching, which calls popFront() on an empty range. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7992] std.algorithm.find breaks in certain circumstances
http://d.puremagic.com/issues/show_bug.cgi?id=7992 --- Comment #3 from hst...@quickfur.ath.cx 2012-10-09 21:31:44 PDT --- https://github.com/D-Programming-Language/phobos/pull/852 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8792] std.algorithm.joiner doesn't return a proper forward range
http://d.puremagic.com/issues/show_bug.cgi?id=8792 --- Comment #1 from hst...@quickfur.ath.cx 2012-10-09 22:15:59 PDT --- Found the bug: joiner.Result.save didn't copy 1 field over, so the saved range is defective. https://github.com/D-Programming-Language/phobos/pull/853 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1352] Can't use module scope operator in base class list.
http://d.puremagic.com/issues/show_bug.cgi?id=1352 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2012-10-10 16:26:27 EST --- *** This issue has been marked as a duplicate of issue 8513 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8714] Missing error message with circular use of CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=8714 --- Comment #2 from github-bugzi...@puremagic.com 2012-10-09 22:33:00 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4eb179d96c4b3402250a707e29ca00ca982cd431 Fix issue 8714 Missing error message with circular use of CTFE The error message was missing, and the supplementary error was also spuriously repeated. https://github.com/D-Programming-Language/dmd/commit/649ad799371e282391813ba9126f5f63f4223656 Merge pull request #1141 from donc/ctfe8714recursive_semantic Fix issue 8714 Missing error message with circular use of CTFE -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8714] Missing error message with circular use of CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=8714 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Version|D2 |D1 --- Comment #3 from yebblies yebbl...@gmail.com 2012-10-10 16:34:37 EST --- Fixed for D2 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
