[Issue 3031] scoped static var conflicts while linking
http://d.puremagic.com/issues/show_bug.cgi?id=3031 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords|patch, wrong-code |link-failure CC||yebbl...@gmail.com Platform|x86 |All Version|2.028 |D1 D2 --- Comment #5 from yebblies yebbl...@gmail.com 2012-07-08 22:15:27 EST --- Issue 5655 is the same sort of thing for lambdas. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8360] New: Destruction of uninitialized temporary struct with assert
http://d.puremagic.com/issues/show_bug.cgi?id=8360 Summary: Destruction of uninitialized temporary struct with assert Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: c...@benjamin-thaut.de --- Comment #0 from Benjamin Thaut c...@benjamin-thaut.de 2012-07-08 06:39:10 PDT --- Created an attachment (id=1123) repro case When a temporary struct is used as the second argument to assert, and the assert is false, the temporary struct gets destructed despite the fact that it was never actually constructed. See attached repro case. Tested with dmd 2.058 and dmd.2059 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8361] New: [ICE] (eh.c line 316) with struct with dtor in assert
http://d.puremagic.com/issues/show_bug.cgi?id=8361
Summary: [ICE] (eh.c line 316) with struct with dtor in assert
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-07-08 07:02:41 PDT ---
Problem found reducing Issue 8360
struct Foo {
string bar = hello;
~this() {}
}
void main() {
assert(true, Foo().bar);
}
DMD 2.060alpha:
Internal error: eh.c 316
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8360] Destruction of uninitialized temporary struct with assert
http://d.puremagic.com/issues/show_bug.cgi?id=8360 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2012-07-08 07:03:05 PDT --- See also probably related Issue 8361 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7965] Invalid outer function scope pointer in some cases
http://d.puremagic.com/issues/show_bug.cgi?id=7965 --- Comment #7 from github-bugzi...@puremagic.com 2012-07-08 12:36:55 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0a612679713182d571f9eaa140dc93451c623d06 fix Issue 7965 more, all nested structs should be initialized by StructLiteralExp, not __init. https://github.com/D-Programming-Language/dmd/commit/51b5b6e09f77eacaffc48fb3c4255e2929832915 Merge pull request #1034 from 9rnsr/fix7965 More fix for issue 7965 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3309] `Traits` : function parameters name
http://d.puremagic.com/issues/show_bug.cgi?id=3309 --- Comment #7 from github-bugzi...@puremagic.com 2012-07-08 13:38:34 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/ab2c26fb3c7ea88183dffe20187c3a87c9c959eb Fix issue 3309 Documentation for the new parameterNames trait https://github.com/D-Programming-Language/d-programming-language.org/commit/12c4c0089d41264da2f9c92f48d24615244c Merge pull request #122 from jmaschme/parameterNames3309 Fix issue 3309 parameter names trait -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7965] Invalid outer function scope pointer in some cases
http://d.puremagic.com/issues/show_bug.cgi?id=7965 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5547] Improve assert to give information on values given to it when it fails
http://d.puremagic.com/issues/show_bug.cgi?id=5547 --- Comment #5 from github-bugzi...@puremagic.com 2012-07-08 13:46:35 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/17db389925581804a3d6d8a10191772077b9713c Bug 5547: assertPred (the druntime part) https://github.com/D-Programming-Language/druntime/commit/ce783fff516d21c253edfecb40982c833add3e4b Merge pull request #41 from kennytm/bug5547_assertPred Bug 5547: assertPred (the druntime part) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4809] Stack trace when throwing exception misses location of the throw statement
http://d.puremagic.com/issues/show_bug.cgi?id=4809 --- Comment #2 from github-bugzi...@puremagic.com 2012-07-08 13:51:50 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/80625a2fc87a830aa538f2f58579019c661ceac9 Merge pull request #80 from rainers/issue4809 Issue 4809: Help the stack walker to find the location of a throw statement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7375] Regression(2.057): Invalid downcast permitted with derived/aliased template classes
http://d.puremagic.com/issues/show_bug.cgi?id=7375 --- Comment #12 from github-bugzi...@puremagic.com 2012-07-08 14:03:31 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/b7bdcdce294729e48b56fa5d8feca5aa9a8cc253 Revert Merge pull request #92 from shoo/fix7020 This reverts commit 29f33bfdc0d36484e77ae8f369656720319f22e3, reversing changes made to f11dd3e56476f75804809ecc14da2e65de3f335e. fixes Issue 7375 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
David Piepgrass qwertie...@gmail.com changed:
What|Removed |Added
CC||qwertie...@gmail.com
--- Comment #70 from David Piepgrass qwertie...@gmail.com 2012-07-08 14:27:53
PDT ---
I must say, I would be entirely opposed to fixing this bug. As far as I can
see, the arguments of Timon and deadalnix have been entirely theoretical,
whereas it's not that hard to envision a situation where the user would fully
desire and expect the wider contract of B to apply even though the static type
is A.
Suppose that D did check *only* A's contract when calling into an A (that might
be a B). I bet that if contracts were widely and exactingly used, cases where
this causes trouble would pop up frequently. The main problem, I think, are
low-level deputies that provide functionality for higher-level clients.
For example, consider a collection that only allows items that match certain
constraints, but the constraints are eliminated in B:
// BTW I wanted to use an interface here, but I get
// missing body { ... } after in or out
// and then if I add a body, D complains that it is not abstract!
class A {
abstract void add(Item item)
in { assert(item.x 0); } body {}
}
class B : A {
override void add(Item item) in {} body {}
}
struct Item { int x; }
Now suppose I write a function that helpfully adds a series of items to an A:
void addAll(A set, Item[] arr...) {
foreach(Item x; arr)
set.add(x);
}
Finally, a client creates a B and tries to add some items to it. That should be
okay, since B has no restrictions on the items:
B b = new B();
b.addAll(Item(-1), Item(-2), Item(-3));
Very few developers would consider this code to be in error. And if there is an
error, where is it?
P.S. Besides which, the implementation difficulties mentioned by Walter in
comment 58 are really big difficulties, that don't seem worth it for what
appears to be a minor behavior tweak.
P.P.S. in http://dlang.org/function.html, surely the syntax described in
D-style Variadic Functions is not the preferred technique since it isn't even
mentioned in TDPL book. Ergo, the Typesafe Variadic Functions section should
be first, and one of the two sections should explain to us why there are two
entirely different syntaxes!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #71 from deadalnix deadal...@gmail.com 2012-07-08 14:50:57 PDT --- The error is in the fact that addAll isn't aware of B. You can solve that easily with metaprograming, or by overloading addAll for B. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #72 from timon.g...@gmx.ch 2012-07-08 14:58:07 PDT ---
(In reply to comment #70)
I must say, I would be entirely opposed to fixing this bug. As far as I can
see, the arguments of Timon and deadalnix have been entirely theoretical,
It is irrelevant who made the arguments.
whereas it's not that hard to envision a situation where the user would fully
desire and expect the wider contract of B to apply even though the static type
is A.
Suppose that D did check *only* A's contract when calling into an A (that
might
be a B). I bet that if contracts were widely and exactingly used, cases where
this causes trouble would pop up frequently. The main problem, I think, are
low-level deputies that provide functionality for higher-level clients.
For example, consider a collection that only allows items that match certain
constraints, but the constraints are eliminated in B:
// BTW I wanted to use an interface here, but I get
// missing body { ... } after in or out
// and then if I add a body, D complains that it is not abstract!
Yah, that's a long standing bug.
class A {
abstract void add(Item item)
in { assert(item.x 0); } body {}
}
class B : A {
override void add(Item item) in {} body {}
}
struct Item { int x; }
Now suppose I write a function that helpfully adds a series of items to an A:
void addAll(A set, Item[] arr...) {
foreach(Item x; arr)
set.add(x);
}
This function is clearly in error. You could do it like this:
class A {
abstract void add(Item item) in { assert(validate(item)); }
bool validate(Item item) const pure { return item.x 0; }
}
class B : A {
override void add(Item item) {}
override bool validate(Item item) const pure { return true; }
}
void addAll(A set, Item[] arr...)in{
foreach(x; arr) assert(set.validate(x));
}body{
foreach(x; arr) set.add(x);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8312] Too many error messages with a writeln of fixed size array
http://d.puremagic.com/issues/show_bug.cgi?id=8312
--- Comment #1 from bearophile_h...@eml.cc 2012-07-08 15:04:14 PDT ---
A related case shown in D.learn (reduced):
import std.stdio: writeln;
void main() {
immutable int[] A = [1];
int[A.length] B;
writeln(A);
writeln(B);
}
DMD 2.060alpha:
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
temp.d(3): Error: Integer constant expression expected instead of (A =
[1]).length
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #73 from timon.g...@gmx.ch 2012-07-08 15:08:47 PDT --- (In reply to comment #70) P.S. Besides which, the implementation difficulties mentioned by Walter in comment 58 are really big difficulties, that don't seem worth it for what appears to be a minor behavior tweak. The reason why it is harder to implement is that it is more general. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8274] thread_attachThis only works for main thread
http://d.puremagic.com/issues/show_bug.cgi?id=8274 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-07-09 00:53:53 CEST --- Fixed in master. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #74 from Stewart Gordon s...@iname.com 2012-07-08 15:59:47 PDT ---
(In reply to comment #72)
(In reply to comment #70)
// BTW I wanted to use an interface here, but I get
// missing body { ... } after in or out
// and then if I add a body, D complains that it is not abstract!
Yah, that's a long standing bug.
See issue 6549.
--
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 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #17 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-08 16:50:05 PDT --- It looks like we've decided that Win2k is not supported anymore. We will probably go with the official policy of only supporting versions of Windows that Microsoft still supports. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #75 from David Piepgrass qwertie...@gmail.com 2012-07-08 17:05:28 PDT --- I must say, I would be entirely opposed to fixing this bug. As far as I can see, the arguments of Timon and deadalnix have been entirely theoretical, It is irrelevant who made the arguments. Relax, I didn't claim that it was relevant. Merely mentioning someone's name does not qualify as an ad-hominim attack. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8362] New: safe function 'benchmark' cannot call system function literal
http://d.puremagic.com/issues/show_bug.cgi?id=8362
Summary: safe function 'benchmark' cannot call system function
literal
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: iteronve...@gmail.com
--- Comment #0 from Caligo iteronve...@gmail.com 2012-07-08 17:41:22 PDT ---
---8--8---
import std.datetime;
void ben(alias fun)() { auto b = std.datetime.benchmark!fun(1); }
struct S{ auto fun() { return 1; } }
unittest {
auto s1 = S();
ben!( {auto r = s1.fun();} )();
}
void main() { }
---8--8---
compiling with `dmd -unittest t1.d` we get:
/home/a/Code/D/compiler/phobos/std/datetime.d(30901): Error: safe function
'benchmark' cannot call system function literal '__lambda1'
t1.d(3): Error: template instance t1.__unittest2.benchmark!(__lambda1) error
instantiating
t1.d(9):instantiated from here: ben!(delegate @system void()
{
int r = s1.fun();
}
)
t1.d(9): Error: template instance t1.__unittest2.ben!(delegate @system void()
{
int r = s1.fun();
}
) error instantiating
/home/a/Code/D/compiler/phobos/std/traits.d(748): Error: safe function
'dummySafeFunc' cannot call system function literal '__lambda1'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8362] safe function 'benchmark' cannot call system function literal
http://d.puremagic.com/issues/show_bug.cgi?id=8362
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-08 18:06:13
PDT ---
Pull request https://github.com/D-Programming-Language/phobos/pull/670 happens
to fix the issue with benchmark but not the underlying bug.
This code also shows it:
import std.traits;
void test(fun...)()
if(areAllSafe!fun)
{}
struct S{ auto fun() { return 1; } }
void main()
{
auto s1 = S();
static assert(!isSafe!({auto r = s1.fun();}));
}
I believe that it's a bug in std.traits.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8362] safe function 'benchmark' cannot call system function literal
http://d.puremagic.com/issues/show_bug.cgi?id=8362
--- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-08 18:07:14
PDT ---
Actually, I left some extra cruft in that example. The actual example is
import std.traits;
struct S{ auto fun() { return 1; } }
void main()
{
auto s1 = S();
static assert(!isSafe!({auto r = s1.fun();}));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1824] Object not const correct
http://d.puremagic.com/issues/show_bug.cgi?id=1824 --- Comment #17 from github-bugzi...@puremagic.com 2012-07-08 19:39:59 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/271085b2d368b5b3046ef95798ae9aec50ab1484 Merge pull request #387 from 9rnsr/constApply Supplemental changes of druntime/pull/72 - Issue 1824 - Object not const correct -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8323] std.string.chompPrefix does not handle differing string types properly
http://d.puremagic.com/issues/show_bug.cgi?id=8323 --- Comment #2 from github-bugzi...@puremagic.com 2012-07-08 20:16:53 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/6203835e5d699f7a37c16625db0776870532761a Fix for issue# 8323. I decided to improve the documentation for some of std.string's functions and ended up optimizing their implementations as well (I benchmarked the new versions against the old versions, so they should definitely be faster). I also ran into bug# 8323, so I fixed it as well. https://github.com/D-Programming-Language/phobos/commit/8c747b0abac930c29cace48c9ca0fe48c04e628e Merge pull request #655 from jmdavis/string Fix for issue# 8323. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8323] std.string.chompPrefix does not handle differing string types properly
http://d.puremagic.com/issues/show_bug.cgi?id=8323 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8323] std.string.chompPrefix does not handle differing string types properly
http://d.puremagic.com/issues/show_bug.cgi?id=8323 --- Comment #3 from github-bugzi...@puremagic.com 2012-07-08 20:20:02 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5cc381c00dc0fca33850e424ba9a0c1e13c16bbe Added fix for issue# 8323 to changelog. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6329] Out of range exceptions not thrown in certain cases
http://d.puremagic.com/issues/show_bug.cgi?id=6329 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|REOPENED|RESOLVED CC||a...@lycus.org Resolution||WORKSFORME --- Comment #16 from Alex R�nne Petersen a...@lycus.org 2012-07-09 06:55:08 CEST --- It may not be solved, but I think that keeping a bug open with no up to date repro is pointless. By all means, let's reopen the bug if a repro is found again, but until then, I think it's reasonable to close this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8362] std.traits.isSafe doesn't work with unsafe lamdba functions
http://d.puremagic.com/issues/show_bug.cgi?id=8362 --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2012-07-08 22:10:46 PDT --- https://github.com/D-Programming-Language/phobos/pull/675 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
