[Issue 8620] Possible circular reference
http://d.puremagic.com/issues/show_bug.cgi?id=8620 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WONTFIX --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-09-04 23:07:19 PDT --- There's no way the compiler can detect, in the general case, infinite recursion at runtime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8601] CTFE Assertion failure (interpret.c) on dstring[].toUpper
http://d.puremagic.com/issues/show_bug.cgi?id=8601
--- Comment #2 from Don clugd...@yahoo.com.au 2012-09-05 00:04:56 PDT ---
The dstring ICE is entirely spurious, the assert is wrong and should be
removed.
The situation with string is a completely unrelated bug; it's a
constant-folding issue. A string initialized with an array literal doesn't
support ~= of a
character of a larger size. Here's a reduced case for that bug.
bool bug8601b()
{
string r = ['x', 'q'];
dchar c = '�';
r ~= c;
assert(r == xq�);
return true;
}
static assert(bug8601b());
bug.d(8): Error: Cannot interpret r ~= c at compile time
This is interesting because an array literal containing multiple code point
characters cannot normally exist.
void main()
{
string yyy = ['�', 'q']; // ok
}
string xxx = ['�', 'q']; // fails
g.d(8): Error: cannot implicitly convert expression ('\xfc') of type wchar to
immutable(char)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8598] [regression 2.059] Calling template function doesn't print instantiated line number
http://d.puremagic.com/issues/show_bug.cgi?id=8598 Damian Ziemba nazriel6...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||nazriel6...@gmail.com Resolution||FIXED --- Comment #3 from Damian Ziemba nazriel6...@gmail.com 2012-09-05 01:56:24 PDT --- Seems to be fixed with https://github.com/D-Programming-Language/dmd/pull/1098 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8526] DMD 2.060 regression: anonymous delegate call in foreach loop
http://d.puremagic.com/issues/show_bug.cgi?id=8526 Damian Ziemba nazriel6...@gmail.com changed: What|Removed |Added CC||nazriel6...@gmail.com --- Comment #1 from Damian Ziemba nazriel6...@gmail.com 2012-09-05 01:52:43 PDT --- Works with DMD 1.075 Looks like it is D2 only. DMD2.060 fails both with m32/m64, on Linux and FreeBSD Current DMD2 trunk still has this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8079] [64 bit] Memory corruption on stack-allocated temporary static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=8079 Damian Ziemba nazriel6...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||nazriel6...@gmail.com Resolution||FIXED --- Comment #3 from Damian Ziemba nazriel6...@gmail.com 2012-09-05 02:05:26 PDT --- Seems to work with DMD 2.060 (and trunk) both with m32 and m64 http://dpaste.dzfl.pl/c6857366 I think we can close this issue as for now although I am not sure what certain Commit fixed it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 d...@dawgfoto.de changed: What|Removed |Added CC||d...@dawgfoto.de --- Comment #8 from d...@dawgfoto.de 2012-09-05 06:03:29 PDT --- And overload resolution occurs _before_ accessibility is checked Not until we fix Bug 3254. The same bug thing now applies to the template access checks. Private symbols are perfectly visibile. They're just not accessible. ... You can check out this explanation with regards to C++ (which is essentially the same) However, it _would_ be really nice if we could at least make it so that private functions weren't considered in overload resolution. In C++ headers are common and allow to hide implementation symbols. D's current workaround are handwritten di files (object, core.thread) but we need a better solution that is scalable and doesn't add redundancy. So far I only came up with HideModuleMembers which hides protected module level symbols but keeps access checks and overloading for nested scopes. https://github.com/D-Programming-Language/dmd/pull/739 Probably it's time to rediscuss this on the mailing list. http://www.digitalmars.com/d/archives/digitalmars/D/visibility_vs._accessibility_of_protected_symbols_157598.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8622] New: Allow labeled breaks to work on *any* block
http://d.puremagic.com/issues/show_bug.cgi?id=8622
Summary: Allow labeled breaks to work on *any* block
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-09-05 06:35:59 PDT ---
D gives the possibility of multiple-breaking out (nested) while/for blocks
using labeled breaks.
I think it would be beneficial to extend this to being able to break out of any
block, as long as it is labeled:
void main()
{
label: {
// ..code..
writefln(code1);
writefln(break..);
break label; // jumps to here:
// ..code..
writefln(code2);
}
// break lands here
writefln(here);
}
The main use case here would actually be to replace the triangle if pattern:
if(condition1)
{
if(condition2)
{
if(condition3)
{
if(condition4)
{
//DO SOMETHING
}
}
}
}
Which would become
conditional_block:
{
if(!condition1) break conditional_block;
if(!condition2) break conditional_block;
if(!condition3) break conditional_block;
if(!condition4) break conditional_block;
//DO SOMETHING
}
The usual workaround to the triangle if pattern is to move it to it's own
function, and *return* from it. The disadvantage is that it burdens the
developer with a whole extra function. The breakable block has the advantage
of not breaking the logic flow of the current function.
Another workaround, the do_while_false is also possible:
do:
{
if(!condition1) break;
if(!condition2) break;
if(!condition3) break;
if(!condition4) break;
//DO SOMETHING
}while(false);
However, my experience is that this pattern tends to be confusing for readers
that expected a loop: The actual condition while(false) is only documented
near the end.
Further more, given both the above workarounds, neither scale should you want
to nest a double break.
Conclusion: Generic breakable labeled blocks. It works better and is
clearer/more verbose.
Thank you/
--
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 #86 from Andrei Alexandrescu and...@metalanguage.com 2012-09-05 07:27:40 PDT --- Forgot to mention - I attached the relevant page from the book (Walter found it) that makes it as clear as it gets how inherited preconditions should behave. -- 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 #85 from Andrei Alexandrescu and...@metalanguage.com 2012-09-05 07:26:07 PDT --- I've had the opportunity to discuss the matter with Bertrand Meyer himself and with a graduate student of his. Bertrand didn't have a defined answer offhand, but opined that the static contract should be evaluated. His book says the same . Julian Tschannen (who allowed me to share his name here) wrote me the following: = 1. Eiffel ECMA standard ([1], Rule 8.23.26) says, that the contract of the dynamic type is checked, i.e. pre_A OR ELSE pre_B (combined precondition, [1], Rule 8.10.5). 2. The Eiffel runtime does actually that, first checks the precondition of the parent class A, and then the precondition of the subclass B. My take on the issue: Dynamically it runs of course without a problem. If you would have a static checker (e.g. the AutoProof tool that I am developing), the code would be rejected due to the static check. Since we strive to get a language that is statically checked and fully verified, it would probably make more sense to just check the precondition of the static type and not take the dynamic type into account for precondition checks, since the client code works just with the given example and is not correct for all possible arguments. Or to be more precise, you could take all the static information into account, but only the static information. It would for example be possible that the client code has some precondition that would make sure that the code is statically correct, even if the call - when looked at in isolation - is statically not correct. = So we currently do what the Eiffel standard and compiler do, but not what would probably be the most sensible thing. In my opinion we should do the right thing and check the contract statically. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8622] Allow labeled breaks to work on *any* block
http://d.puremagic.com/issues/show_bug.cgi?id=8622 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2012-09-05 07:59:03 PDT --- This is a sensible feature. However, it has several workarounds and doesn't enable new patterns. I think we should make additions to the language only if they have major usefulness. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8622] Allow labeled breaks to work on *any* block
http://d.puremagic.com/issues/show_bug.cgi?id=8622 --- Comment #2 from monarchdo...@gmail.com 2012-09-05 08:31:06 PDT --- Got it. Thanks. -- 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 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WONTFIX --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2012-09-05 15:35:51 PDT --- As I commented on the pull request: I have two problems with this: 1. Currently, there are so many unittests in Phobos that the compiler sometimes runs out of memory. This will add a lot more and may push a lot more over the edge. 2. I am not too happy about the dependencies on specific library names and functionality. On further reflection, I think that this is more properly the domain of a library template, such as testEqual(arg1, arg2); std.math.approxEqual can easily be extended to print its args on failure. -- 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 #7 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-05 15:45:23 PDT --- On further reflection, I think that this is more properly the domain of a library template I'm fine with having a helper function that does this, but the whole reason that this enhancement was created in the first place was because enough folks in the newsgroup thought that that it should be built into assert rather than creating a new function to do it. Though it should be noted that the library function does tend to cause memory issues as well, since you end up with a lot of different instantiations for it. -- 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 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #8 from bearophile_h...@eml.cc 2012-09-05 16:07:28 PDT --- (In reply to comment #6) Currently, there are so many unittests in Phobos that the compiler sometimes runs out of memory. This will add a lot more and may push a lot more over the edge. A large program written by D users risks having the same amount of unit-tests, so this is a general problem, not just of Phobos. So maybe the right solution is not to keep assert() dumb, but to find ways to compile unit-tests using much less memory. I think this idea also goes well with compiling unit-tests more independently from each other, to give the user a simple summary of what tests have failed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8623] New: Multiple function match needs to print file+line numbers
http://d.puremagic.com/issues/show_bug.cgi?id=8623
Summary: Multiple function match needs to print file+line
numbers
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: trivial
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-09-05
16:22:55 PDT ---
alias int LONG;
void test(int* x) { }
void test(LONG* x) { }
void main()
{
test(null);
}
test.d(21): Error: function test.test called with argument types:
((typeof(null)))
matches both:
test.test(int* x)
and:
test.test(int* x)
This is a simple case but it would be useful to file+line info since it helps
me find codegenerator bugs. Error should be:
test.d(21): Error: function test.test called with argument types:
((typeof(null)))
matches both:
test.d(17): test.test(int* x)
and:
test.d(18): test.test(int* x)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #9 from timon.g...@gmx.ch 2012-09-05 17:59:31 PDT --- (In reply to comment #6) Jonathan's summary is correct. It shouldn't be. The summary obviously describes horribly broken behaviour. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #10 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-05 18:16:11 PDT --- It shouldn't be. The summary obviously describes horribly broken behaviour. It describes how it works in C++ which is exactly how it works in D. It's that way by design, and anything else would require that the language be changed. What many have argued for is that private symbols should be hidden (or at least not be considered in overload resolution when not accessible or otherwise cause conflicts with accessible symbols), which I think would be a major improvement, but that's not the way that it currently works or is ever expected to work unless you can convince Walter to change it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #11 from timon.g...@gmx.ch 2012-09-05 18:49:03 PDT --- (In reply to comment #10) It shouldn't be. The summary obviously describes horribly broken behaviour. It describes how it works in C++ Irrelevant. which is exactly how it works in D. It's that way by design, This does not matter either. It is an incorrect design. and anything else would require that the language be changed. What many have argued for is that private symbols should be hidden (or at least not be considered in overload resolution when not accessible or otherwise cause conflicts with accessible symbols), which I think would be a major improvement, These are not conflicts. The compiler is deliberately lying about this. but that's not the way that it currently works or is ever expected to work unless you can convince Walter to change it. Introducing a private module scope symbol currently is a breaking interface change (even in code that does not use any metaprogramming!) This is ridiculous. I assume that Walter will figure it out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8579] Default parameter appears a part of typeof().stringof of a function variable
http://d.puremagic.com/issues/show_bug.cgi?id=8579 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-09-05 18:53:53 PDT --- https://github.com/D-Programming-Language/dmd/pull/1102 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3646] Default values of function arguments are ignored when instantiating a template.
http://d.puremagic.com/issues/show_bug.cgi?id=3646 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #11 from Kenji Hara k.hara...@gmail.com 2012-09-05 18:53:52 PDT --- D2 pull: https://github.com/D-Programming-Language/dmd/pull/1102 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3866] anonymous delegate with default parameters cross-talks to another anonymous delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3866 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #13 from Kenji Hara k.hara...@gmail.com 2012-09-05 19:02:04 PDT --- In the forum discussion: http://forum.dlang.org/thread/mailman.1421.1346020012.31962.digitalmar...@puremagic.com We decided to improve the status for default argument issues. Then I've created a new pull which contains some fixups for this issue. D2 pull: https://github.com/D-Programming-Language/dmd/pull/1102 So I reopen this for D2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8624] New: CTFE: 0x6161636772 == 0x4161636772
http://d.puremagic.com/issues/show_bug.cgi?id=8624
Summary: CTFE: 0x6161636772 == 0x4161636772
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-09-05
19:17:47 PDT ---
dmd 2.060 x64 linux.
code:
int generateHashAndValueArrays()
{
import std.string;
assert(H(a) != H(A), xformat(%x == %x, H(a), H(A)));
return 1;
}
enum s = (generateHashAndValueArrays());
ulong H(string str)
{
if(str[0] == 'a') return 0x6161636772;
return 0x4161636772;
}
fireworks:
HtmlEntities.d(4): Error: ['6','1','6','1','6','3','6','7','7','2','
','=','=',' ','4','1','6','1','6','3','6','7','7','2'][0LU..24LU]
ehh,
HtmlEntities.d(4): Error: 6161636772 == 4161636772
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6180] Private has no effect on types in modules
http://d.puremagic.com/issues/show_bug.cgi?id=6180 --- Comment #12 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-05 19:26:03 PDT --- D takes it access modifier design from C++, and it's purely a question of accessibility, not visibility, even if many people expect it to affect visibility. AFAIK, Walter doesn't think that there's anything wrong with it. I have no idea how easy it will be to convince him otherwise. But if you don't like the current design, then start a discussion in the newsgroup on it and convince Walter. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5587] Use __LINE__ to pick number in unittest block names
http://d.puremagic.com/issues/show_bug.cgi?id=5587 --- Comment #12 from github-bugzi...@puremagic.com 2012-09-05 19:47:04 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8f478ace129b50844aed91b5be82a78238cbb1dc Bug 5587: Give unit test name by __LINE__. This commit appends 'Lxx' to the unittest's mangled name. The user can get the line number from the traceback: 5 x 0x91c5 onAssertErrorMsg + 73 6 x 0x9206 onUnittestErrorMsg + 26 7 x 0x00013199 _d_unittestm + 45 8 x 0x19d7 void x.__unittest_fail(int) + 27 9 x 0x1a0a void x.__unittestL13_1() + 46 ^^^ line 13 https://github.com/D-Programming-Language/dmd/commit/d3669f79813ba314768daf43eb1bfa90dac4c4a1 Merge pull request #264 from kennytm/bug5587_unittestWithLine Bug 5587: Give unit test name by __LINE__. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5587] Use __LINE__ to pick number in unittest block names
http://d.puremagic.com/issues/show_bug.cgi?id=5587 --- Comment #14 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-05 19:53:54 PDT --- Woohoo! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5587] Use __LINE__ to pick number in unittest block names
http://d.puremagic.com/issues/show_bug.cgi?id=5587 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Walter Bright bugzi...@digitalmars.com 2012-09-05 19:50:07 PDT --- Added patch to D1, too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8625] New: foreach doesn't do implicit conversions on associative arrays and opApply
http://d.puremagic.com/issues/show_bug.cgi?id=8625
Summary: foreach doesn't do implicit conversions on associative
arrays and opApply
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nilsboss...@googlemail.com
--- Comment #0 from Nils nilsboss...@googlemail.com 2012-09-05 20:41:43 PDT
---
This should compile:
void main() {
int[int] aa;
foreach(long k, long v; aa) {} // fails on both k and v
// test.d(3): Error: foreach: index must be type int, not long
// test.d(3): Error: foreach: value must be type int, not long
static struct OpApply {
int opApply(int delegate(int)) {return 0;}
}
foreach(long x; OpApply()) {} // fails
// test.d(10): Error: cannot uniquely infer foreach argument types
// In contrast, it does work on plain arrays and ranges:
int[] a;
foreach(long x; a) {} // ok
static struct Range {
@property bool empty() {return false;}
@property int front() {return 0;}
void popFront() {}
}
foreach(long x; Range()) {} // ok
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
