[Issue 4728] New: Crash by protected/private constructor in an other module
http://d.puremagic.com/issues/show_bug.cgi?id=4728 Summary: Crash by protected/private constructor in an other module Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Keywords: ice-on-invalid-code Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: rayerd@gmail.com --- Comment #0 from Haruki Shigemori 2010-08-26 00:45:57 PDT --- // a.d import b; void main() { new A(); } // b.d class A { protected this(){} } When these source codes are compiled with dmd trunk r628, dmd outputs a correct error message and crashes. >dmd a b a.d(4): Error: class b.A member this is not accessible <-- crash!! The cause of the crash is an access to the null pointer as shown below. // toctype.c ... type *TypeFunction::toCtype() { type *t; if (ctype) return ctype; if (1) { param_t *paramtypes; tym_t tyf; type *tp; paramtypes = NULL; size_t nparams = Parameter::dim(parameters); for (size_t i = 0; i < nparams; i++) { Parameter *arg = Parameter::getNth(parameters, i); tp = arg->type->toCtype(); if (arg->storageClass & (STCout | STCref)) { // C doesn't have reference types, so it's really a pointer // to the parameter type tp = type_allocn(TYref, tp); } param_append_type(¶mtypes,tp); } tyf = totym(); t = type_alloc(tyf); t->Tflags |= TFprototype; if (varargs != 1) t->Tflags |= TFfixed; ctype = t; t->Tnext = next->toCtype(); // next is null t->Tnext->Tcount++; t->Tparamtypes = paramtypes; } ctype = t; return t; } ... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4726] writeln(0.0 / 0.0) prints -nan
http://d.puremagic.com/issues/show_bug.cgi?id=4726 --- Comment #2 from bearophile_h...@eml.cc 2010-08-26 00:50:46 PDT --- OK. Thank you for your answer. I will not reopen this bug because it's a minor thing, but I don't like it because: >From a purely ideal point of view, a NaN isn't a number, so it can't be positive or negative, it's "undefined", that is not negative. In 0.0/0.0 both values are positive, so if you extend the semantics of division between two positive real numbers, the result can't be negative. And because no other language I know of (including D printf) seems to print a "negative nan" in that situation: --- In D (2.048) if you run this program: import std.stdio; void main() { printf("%f\n", 0.0 / 0.0); } It prints "nan". --- This D1 program (dmd 1.026): import std.stdio; void main() { writefln("%f", 0.0 / 0.0); } Prints "nan". --- In C if you run this program: #include "stdio.h" int main() { printf("%f\n", 0.0 / 0.0); return 0; } It prints "nan". --- In Scala language, this program: import java.io.{BufferedReader, InputStreamReader} object Main { def main(args: Array[String]) { System.out.println(0.0 / 0.0); } } Prints "NaN". --- In Haskell (that is a quite mathematical-oriented language), this program: main = do putStr (show (0.0 / 0.0)) Prints "NaN". --- In F#, this program: open System do System.Console.Write(0.0 / 0.0) Prints "NaN". --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #10 from Steven Schveighoffer 2010-08-26 04:56:47 PDT --- I checked in hopefully a fix for this. changeset http://www.dsource.org/projects/phobos/changeset/1929 Note, I changed the interface of Appender slightly to be safer. Instead of taking an array reference pointer, it takes an array. This means your original array passed in will *not* be appended to. To get the resulting data after appending, use the data method. I didn't find any cases in Phobos that were adversely affected by this change (but I did have to change a few modules that used appender in unit tests). I tested the new version against the original code in this bug, and Don's code in comment 8, both no longer exhibit errors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4729] New: std.algorithm: atrange iota behaviour
http://d.puremagic.com/issues/show_bug.cgi?id=4729 Summary: std.algorithm: atrange iota behaviour Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Optlink AssignedTo: nob...@puremagic.com ReportedBy: necrom...@gmail.com --- Comment #0 from Max Klyga 2010-08-26 05:16:40 PDT --- import std.stdio, std.algorithm, std.range; void main() { filter!((int n) { write(n, ' '); return 0; })(iota(1, 10)); //writes: 1 2 3 4 5 6 7 8 9 writeln(); reduce!"0"( filter!((int n) { write(n, ' '); return 1; })(iota(1, 10)) ); //writes: 1 2 3 4 5 6 7 8 9 writeln(); reduce!"0"( filter!((int n) { write(n, ' '); return 0; })(iota(1, 10)) ); //Never stops writing numbers } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 --- Comment #11 from nfx...@gmail.com 2010-08-26 05:20:08 PDT --- This is still full of dirty runtime calls and attempts to emulate half of lifetime.d (though the worst part is commented). Why doesn't it simply use the D standard way to re-allocate an array, and then use array.capacity to see how much can be safely appended? Something along the lines of: private struct Data { T[] arr; size_t user_length; } Data _data; void put(T item) { if (_data.user_length == arr.length) { size_t newcapacity = something larger than user_length; reallocate(newcapacity); } _data.arr[_data.user_length++] = item; } void reallocate(size_t newcapacity) { _data.arr.length = newcapacity; //include the data "overallocated" by the runtime into the array size_t realcap = _data.arr.capacity; _data.arr.length = realcap; } T[] data() { T[] arr = _data.arr[0.._data.user_length]; _data = _data.init; assumeSafeAppend(arr); return arr; } Or did I overlook something. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 --- Comment #12 from Steven Schveighoffer 2010-08-26 05:51:15 PDT --- (In reply to comment #11) > This is still full of dirty runtime calls and attempts to emulate half of > lifetime.d (though the worst part is commented). Why are runtime calls dirty? I don't use any undocumented runtime functions... It doesn't emulate lifetime, except for the newCapacity function (which arguably could be a call into the runtime, but it's a simple enough function, and doesn't really have to be consistent with the runtime), and the use of GC.extend. I'm notably not trying to store the length inside the memory block. > Why doesn't it simply use the D standard way to re-allocate an array, and then > use array.capacity to see how much can be safely appended? Because the call to the runtime cannot be inlined, and is much slower than simply dereferencing a pointer. Appender is supposed to be as fast as possible at appending. If you want to use built-in appending, just use it. Appender is for getting the highest possible performance out of an array. > > Something along the lines of: > > private struct Data { >T[] arr; >size_t user_length; > } > > Data _data; > > void put(T item) { >if (_data.user_length == arr.length) { > size_t newcapacity = something larger than user_length; > reallocate(newcapacity); >} >_data.arr[_data.user_length++] = item; > } > > void reallocate(size_t newcapacity) { >_data.arr.length = newcapacity; >//include the data "overallocated" by the runtime into the array >size_t realcap = _data.arr.capacity; >_data.arr.length = realcap; > } > > T[] data() { >T[] arr = _data.arr[0.._data.user_length]; >_data = _data.init; >assumeSafeAppend(arr); >return arr; > } > > Or did I overlook something. This is a different way of doing it, though I'd probably replace reallocate with a standard ~=. I think your way would work fine. I agree your way seems more congruent with the runtime. I wonder if there are any advantages to doing it that way? I think the Appender I committed is going to be slightly faster in the long run, because it avoids using runtime appending at all. However, it has some limitations in that it cannot use the rest of a passed in memory block (i.e. the space beyond the initial array). But your code gave me an idea of how to achieve that. I think this should work: this(T[] arr) { _data = new Data; _data.arr = arr; auto cap = arr.capacity; if(cap > origlen) arr.length = cap; // use up the rest of the block _data.capacity = arr.length; } I'll add this change too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4729] std.algorithm: strange iota behaviour
http://d.puremagic.com/issues/show_bug.cgi?id=4729 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc Summary|std.algorithm: atrange iota |std.algorithm: strange iota |behaviour |behaviour --- Comment #1 from bearophile_h...@eml.cc 2010-08-26 06:04:08 PDT --- It seems a iota() problem. import std.algorithm: reduce, filter; import std.range: iota; void main() { reduce!"0"(filter!((int a){ return false; })(iota(1))); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 --- Comment #13 from nfx...@gmail.com 2010-08-26 06:20:17 PDT --- (In reply to comment #12) > Why are runtime calls dirty? I don't use any undocumented runtime > functions... Because they do more work than necessary and rely on more implementation details than necessary. Also, more bugs (oh hey look, we're posting in a bug report). I'm most worried about the assumptions of the array memory layout. > Because the call to the runtime cannot be inlined, and is much slower than > simply dereferencing a pointer. Appender is supposed to be as fast as > possible > at appending. My code only calls runtime functions when the capacity is exhausted. As long as there's enough capacity, not a single runtime function is called on appending. It's really similar to all the code that has been in Appender before, except less dirty. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 --- Comment #8 from Steven Schveighoffer 2010-08-26 06:22:33 PDT --- This helps, but only reduces it to 20 seconds (but a 66% reduction is pretty good!). I ran another round of profiling, and found we have a new bottleneck: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 75.79 6.51 6.51 8103 0.80 0.80 TemplateDeclaration::toJsonBuffer(OutBuffer*) 3.14 6.78 0.27 1668093 0.00 0.00 StructDeclaration::semantic(Scope*) 2.10 6.96 0.181 180.00 180.00 do32bit(FL, evc*, int) 1.98 7.13 0.1715445 0.01 0.01 EnumDeclaration::toJsonBuffer(OutBuffer*) 0.70 7.19 0.06 656268 0.00 0.00 Port::isSignallingNan(long double) 0.47 7.23 0.04 915560 0.00 0.00 StructDeclaration::toCBuffer(OutBuffer*, HdrGenState*) 0.47 7.27 0.04 Dsymbol::searchX(Loc, Scope*, Identifier*) This time, I question whether toJsonBuffer should be called at all, as I'm not outputting any JSON data? Walter, reopen if you think this could still use improvement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4730] New: std.c.stdlib.exit in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4730 Summary: std.c.stdlib.exit in CTFE Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-08-26 06:25:39 PDT --- This enhancement request comes from bug 4005 Currently (dmd 2.048) the following program prints: test.d(3): Error: exit cannot be interpreted at compile time, because it has no available source code test.d(6): Error: cannot evaluate foo() at compile time test.d(6): Error: static assert (foo() == 100) is not evaluatable at compile time import std.c.stdlib: exit; int foo() { exit(1); return 100; } static assert(foo() == 100); void main() {} I'd like exit() to work at compile-time too, and stop the compilation gracefully (dmd return value is the value given to exit()). See also bug 3952 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 --- Comment #14 from Steven Schveighoffer 2010-08-26 06:30:03 PDT --- (In reply to comment #13) > (In reply to comment #12) > > Why are runtime calls dirty? I don't use any undocumented runtime > > functions... > > Because they do more work than necessary and rely on more implementation > details than necessary. Also, more bugs (oh hey look, we're posting in a bug > report). I'm most worried about the assumptions of the array memory layout. I'm not assuming anything about the memory layout. GC.qalloc gives me a block of data, and I'm using the data. Its interface is well defined without any hidden assumptions. Besides, you are calling the same runtime functions, just using a different interface. I don't see how one is more "dirty" than the other, we are both using well-documented runtime functions. > > > Because the call to the runtime cannot be inlined, and is much slower than > > simply dereferencing a pointer. Appender is supposed to be as fast as > > possible > > at appending. > > My code only calls runtime functions when the capacity is exhausted. As long > as > there's enough capacity, not a single runtime function is called on appending. > It's really similar to all the code that has been in Appender before, except > less dirty. Your code calls the lifetime runtime functions, which call the GC runtime functions. My code just calls the GC functions, skipping the lifetime functions. Like your code, mine only calls runtime functions on exhaustion. BTW, the statement I was responding to asked why you can't just use runtime functions to determine capacity, I interpreted that as you wishing to use the runtime management of array memory for every append. I hadn't read your code yet. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4021] [CTFE] AA rehash
http://d.puremagic.com/issues/show_bug.cgi?id=4021 --- Comment #3 from bearophile_h...@eml.cc 2010-08-26 06:31:44 PDT --- With dmd 2.048 the error message is a little different: ...\dmd\src\druntime\import\object.di(354): Error: _aaRehash cannot be interpreted at compile time, because it has no available source code test.d(3): Error: cannot evaluate aa.rehash() at compile time test.d(6): Error: cannot evaluate foo() at compile time test.d(6): Error: cannot evaluate foo() at compile time -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3976] segfault on anonymous struct/union
http://d.puremagic.com/issues/show_bug.cgi?id=3976 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Don 2010-08-26 07:40:22 PDT --- (In reply to comment #1) > Okay, for some reason my test case doesn't seem to be working. I'm sure it was > earlier, but I deleted the file, etc. > > Here it is if anyone cares: > > http://personal.utulsa.edu/~ellery-newcomer/dxl.zip > > unzip it and run dmd @kmd. There is no kmd file. Also this code seems to use Tango (dunno which version!). So it's not a usable test case. But I'm pretty sure this is the same as 4543. Reopen if you think it is not the same, and have some kind of usable test case. *** This issue has been marked as a duplicate of issue 4543 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4543] Regression(1.054, 2.038) typedef circular definition and segfault
http://d.puremagic.com/issues/show_bug.cgi?id=4543 Don changed: What|Removed |Added CC||ellery-newco...@utulsa.edu --- Comment #7 from Don 2010-08-26 07:40:22 PDT --- *** Issue 3976 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 4729] std.algorithm: strange iota behaviour
http://d.puremagic.com/issues/show_bug.cgi?id=4729 --- Comment #2 from Max Klyga 2010-08-26 07:50:27 PDT --- This bug was introduced in 2.048, as is 2.047 iota stops but fails shortly after: src/phobos/std/algorithm.d(279): Enforcement failed -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717 --- Comment #8 from bearophile_h...@eml.cc 2010-08-26 07:56:20 PDT --- See also bug 4124 and bug 4123 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4139] Forward reference error in front() of iterable struct
http://d.puremagic.com/issues/show_bug.cgi?id=4139 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from bearophile_h...@eml.cc 2010-08-26 07:58:48 PDT --- This bug is missing in dmd 2.048, so I close it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4731] New: cannot call protected base class method by using base class name
http://d.puremagic.com/issues/show_bug.cgi?id=4731 Summary: cannot call protected base class method by using base class name Product: D Version: unspecified Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: s...@extrawurst.org --- Comment #0 from Stephan Dilly 2010-08-26 09:41:13 PDT --- the way how one has to invoke protected base class methods in D seems to be inconsistent. why do i have to use the super keyword ? using the base class name works in case of being public, why is protected any different ? module Foo; class Base { protected void foo() {} } module main; import Foo; class Super : Base { override protected void foo() {super.foo();} // works //override void foo() {Base.foo();} // does not work: //Error: class Foo.Base member foo is not accessible } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 --- Comment #15 from nfx...@gmail.com 2010-08-26 10:12:08 PDT --- (In reply to comment #14) > I'm not assuming anything about the memory layout. GC.qalloc gives me a block > of data, and I'm using the data. Its interface is well defined without any > hidden assumptions. That mess is mostly gone, but there's still that commented stuff. Will it be readded later? > Besides, you are calling the same runtime functions, just using a different > interface. I don't see how one is more "dirty" than the other, we are both > using well-documented runtime functions. It doesn't zero the additional memory returned by GC.extend(). If precise GC is introduced, that won't be handled correctly either. > Your code calls the lifetime runtime functions, which call the GC runtime > functions. My code just calls the GC functions, skipping the lifetime > functions. Like your code, mine only calls runtime functions on exhaustion. The only real overhead is due to array initialization. If that is really so important, the runtime should provide a clean interface to allocate arrays uninitialized (or zeroed if not NO_SCAN). Basically a _d_arraysetlengthT without the initialization code. That would be useful for other code too; most time you create an array, you overwrite all its contents anyway. Keep in mind that optimizing the runtime code might be more worthwhile than optimizing Appender. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4713] PATCH for interface generation: cleanup, bugfixes and prettyprinting
http://d.puremagic.com/issues/show_bug.cgi?id=4713 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2010-08-26 11:22:18 PDT --- Did bugfixes part of the patches. http://www.dsource.org/projects/dmd/changeset/629 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 --- Comment #9 from Steven Schveighoffer 2010-08-26 11:42:02 PDT --- (In reply to comment #8) > Flat profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds secondscalls ms/call ms/call name > 75.79 6.51 6.51 8103 0.80 0.80 > TemplateDeclaration::toJsonBuffer(OutBuffer*) > 3.14 6.78 0.27 1668093 0.00 0.00 > StructDeclaration::semantic(Scope*) That table of functions is invalid -- I somehow compiled dmd wrong when running that profile. I think I used a unit test build. However, that was only the profiled version, the non-profiled version still takes 20 seconds to compile dcollections. In any case, here is the correctly profiled version's heavy hitters: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 80.31 11.9911.9919000 0.63 0.63 searchfixlist 0.67 12.09 0.10 203173 0.00 0.00 StringTable::search(char const*, unsigned int) 0.60 12.18 0.09 369389 0.00 0.00 Lexer::scan(Token*) 0.54 12.26 0.08 953613 0.00 0.00 ScopeDsymbol::search(Loc, Identifier*, int) 0.47 12.33 0.07 1449798 0.00 0.00 calccodsize Note, this profile is different from the first in that I was compiling the *entire* dcollections library, not just HashMap (which is now bearable due to the improved performance!). This is why the # calls is much higher on this one compared to the original. So the last significant performance problem here is searchfixlist. Looking back, it was 2% of the runtime before, now it's jumped to 80%. Looking at the function in backend/cod3.c, it appears to be another linear search through a linked list. I understand much less about this function than the other, so I'm not sure how/if it should be solved. Perhaps another hash map? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4732] New: __traits(identifier) performs constant folding on symbols
http://d.puremagic.com/issues/show_bug.cgi?id=4732 Summary: __traits(identifier) performs constant folding on symbols Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: patch, rejects-valid Severity: minor Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: rsi...@gmail.com --- Comment #0 from Shin Fujishiro 2010-08-26 12:13:50 PDT --- Created an attachment (id=741) Patch against dmd r621 __traits(identifier) tries to fold its argument to a constant. And symbols of manifest constants cannot be obtained via the traits: test.d enum symbol = 42; pragma(msg, __traits(identifier, symbol), " = ", symbol); % dmd -c -o- test test.d(2): Error: argument 42 has no identifier false = 42 For the 'identifier' traits, folding an argument to a constant does not make sense. The proposed patch fixes the problem by disabling constfold on arguments as done in the 'isSame' traits. With the patch, the result gets corrected: % dmd-patched -c -o- test symbol = 42 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4721] compilation slow when compiling unittests on dcollections
http://d.puremagic.com/issues/show_bug.cgi?id=4721 bearophile_h...@eml.cc changed: What|Removed |Added Status|RESOLVED|REOPENED CC||bearophile_h...@eml.cc Resolution|FIXED | --- Comment #10 from bearophile_h...@eml.cc 2010-08-26 13:19:39 PDT --- Reopened, because you have added here a second different performance bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4602] Header generation turns 'typeof(x)(...)' into C-style cast
http://d.puremagic.com/issues/show_bug.cgi?id=4602 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Don 2010-08-26 13:25:35 PDT --- Fixed http://www.dsource.org/projects/dmd/changeset/629 as part of bug 4713. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4733] New: Possible bugs caused by dynamic arrays in boolean evaluation context
http://d.puremagic.com/issues/show_bug.cgi?id=4733 Summary: Possible bugs caused by dynamic arrays in boolean evaluation context Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-08-26 14:12:04 PDT --- In Python it is a normal idiom to test for collection emptiness just putting their name in a boolean evaluation context (this is an idom valid for all Python collections): arr = [1] assert arr But in D similar code causes troubles, this differt code shows an example: void main() { int[] arr = [1]; int* orig_ptr = arr.ptr; arr.length = 0; assert(!!arr); // this doesn't assert assert(arr.ptr == orig_ptr); // this doesn't assert } !!arr is true because while arr.length is zero, arr.ptr is not null. To avoid possible bugs (for example for programmers coming from Python language) I suggest to turn "if(arr)" into a syntax error, forcing to use "if(arr.length)" or "if(arr.ptr)" or similar things, and you avoid possible bugs. In the uncommon cases where you want to test both fields to be empty, you may use "if(arr.length || arr.ptr)" or "if(arr.length != arr.init)" or similar things. The semantics of "if(aa)" and "if(static_arr)", the first tests if the reference is null, the second if all items are empty. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4735] New: class that implements interface can override a static method
http://d.puremagic.com/issues/show_bug.cgi?id=4735 Summary: class that implements interface can override a static method Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2010-08-26 14:18:14 PDT --- According to the docs: "Classes that inherit from an interface may not override final or static interface member functions." module test; void main() { } interface D { void bar(); static void foo() { } final void abc() { } } class C : D { void bar() { } // ok void foo() { } // passes, but should not } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4734] New: immutable return type specifier without parantheses confuses the compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4734 Summary: immutable return type specifier without parantheses confuses the compiler Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2010-08-26 14:15:31 PDT --- import std.stdio; class Test { immutable char foo() { return 'z'; } } unittest { auto test = new Test; test.foo(); } void main() { } error: test2.d(16): Error: function test2.Test.foo () immutable is not callable using argument types () Note that using const instead of immutable works. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4080] Patch for building dynamic libraries on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=4080 --- Comment #5 from Walter Bright 2010-08-26 14:21:48 PDT --- http://www.dsource.org/projects/dmd/changeset/372 I changed the location of the new files to be more consistent with druntime's existing conventions: Adding src\core\sys\osx\mach\dyld.d Adding src\core\sys\osx\mach\getsect.d Adding src\core\sys\osx\mach\loader.d Adding src\rt\dylib_fixes.c Adding src\rt\image.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3976] segfault on anonymous struct/union
http://d.puremagic.com/issues/show_bug.cgi?id=3976 --- Comment #4 from Ellery Newcomer 2010-08-26 14:25:04 PDT --- (In reply to comment #3) > > There is no kmd file. Also this code seems to use Tango (dunno which > version!). > So it's not a usable test case. But I'm pretty sure this is the same as 4543. > Reopen if you think it is not the same, and have some kind of usable test > case. > > *** This issue has been marked as a duplicate of issue 4543 *** I have little to no recollection of filing this isssue (and I agree it's pretty bad), but I don't think issue 4543 sounds like what this one was. I'll try digging things up this weekend. Sorry to waste your time, Don. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4736] New: http://www.digitalmars.com/d/2.0/hash-map.html
http://d.puremagic.com/issues/show_bug.cgi?id=4736 Summary: http://www.digitalmars.com/d/2.0/hash-map.html Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2010-08-26 14:27:13 PDT --- Example under "Using Classes as the KeyType" has some typos (f instead of foo), fix to: class Foo { int a, b; hash_t toHash() { return a + b; } bool opEquals(Object o) { Foo foo = cast(Foo) o; return foo && a == foo.a && b == foo.b; } int opCmp(Object o) { Foo foo = cast(Foo) o; if (!foo) return -1; if (a == foo.a) return b - foo.b; return a - foo.a; } } Example under "Using Structs or Unions as the KeyType" has a typo (s instead of str) fix to: import std.string; struct MyString { string str; const hash_t toHash() { hash_t hash; foreach (char c; str) hash = (hash * 9) + c; return hash; } const bool opEquals(ref const MyString s) { return std.string.cmp(this.str, s.str) == 0; } const int opCmp(ref const MyString s) { return std.string.cmp(this.str, s.str); } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4737] New: enum breaks linker when passed to typeid()
http://d.puremagic.com/issues/show_bug.cgi?id=4737 Summary: enum breaks linker when passed to typeid() Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2010-08-26 14:34:39 PDT --- module test; import std.stdio; unittest { enum X { A = 3, B, C } X x; write(typeid(x)); write(typeid(X)); } void main() { } Error 42: Symbol Undefined _D4test11__unittest1FZv1X6__initZ Sometimes it will compile, but then the app crashes and I get an access violation message in console. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4734] immutable return type specifier without parantheses confuses the compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4734 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #1 from Jonathan M Davis 2010-08-26 14:44:23 PDT --- Unfortunately, this is not a bug. Putting either const or immutable on a function - be it on the left of the function signature or the right - makes that function immutable. If you want the return type to be const or immutable, you _must_ use parens. As I understand it, this was done to make const and immutable work the sames as modifiers like private, public, pure, and nothrow (which mean the same thing regardless of which side of the function that they're on). A number of use would like const and immutable to have to be on the right if you want to make the function const or immutable, but Walter doesn't agree, so it doesn't work that way. So, your function declaration is making the function immutable, _not_ the return type. The reason why using const with your unit test works but immutable does not is because both mutable and immutable values can be used with const functions, but only immutable ones can be used with immutable functions. immutable test = new Test; test.foo(); should work just fine with the way that you declared the function. Now, I think that the error message definitely needs some work; it should indicate that the variable needs to be immutable rather than talking about the function arguments (it's probably doing that because the this pointer is an invisible function argument), but it is essentially correct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4734] immutable return type specifier without parantheses confuses the compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4734 --- Comment #2 from Andrej Mitrovic 2010-08-26 14:53:11 PDT --- You are absolutely right. I forgot about the ability to make functions themselves const/immutable. It would really help if that right-side rule was in place, because all this will do right now is cause confusion (unless we get a nicer error message, in which case we can keep the flexibility I think..). So maybe I should change this to an enhancement request for a better error message. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4734] immutable return type specifier without parantheses confuses the compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4734 Stephan Dilly changed: What|Removed |Added CC||s...@extrawurst.org --- Comment #3 from Stephan Dilly 2010-08-26 15:14:48 PDT --- (In reply to comment #2) > You are absolutely right. I forgot about the ability to make functions > themselves const/immutable. It would really help if that right-side rule was > in > place, because all this will do right now is cause confusion (unless we get a > nicer error message, in which case we can keep the flexibility I think..). > > So maybe I should change this to an enhancement request for a better error > message. I disagree, just like any other storage class the current annotating enables the user to group blocks of methods with equivalent storage classes like this: class Foo{ static{ void foo(); } const{ const(ConstReturnVal) bar(); } } it is nothing but consistent and should stay as it is. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4734] immutable return type specifier without parantheses confuses the compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4734 Stephan Dilly changed: What|Removed |Added Severity|normal |enhancement --- Comment #4 from Stephan Dilly 2010-08-26 15:16:58 PDT --- (In reply to comment #3) > (In reply to comment #2) > > You are absolutely right. I forgot about the ability to make functions > > themselves const/immutable. It would really help if that right-side rule > > was in > > place, because all this will do right now is cause confusion (unless we get > > a > > nicer error message, in which case we can keep the flexibility I think..). > > > > So maybe I should change this to an enhancement request for a better error > > message. > > it is nothing but consistent and should stay as it is. sorry i should have read to the end. i aggree that the error message could be improved ;) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4734] immutable return type specifier without parantheses confuses the compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4734 --- Comment #5 from Jonathan M Davis 2010-08-26 15:47:47 PDT --- The error message definitely needs to be improved. However, if you're arguing for consistency, you could easily argue that the current way is not consistent because it's not consistent with variable declarations. If I declare const T foo; then foo is going to be a const T. However, if I declare const T foo() {} then now T is not const. Rather the object that foo is a member of is const. So, the current situation is _not_ completely consistent. It chooses to be consistent with one feature and not another because it can't be consistent with both. However, anyone coming from a C++ background will expect that function declaration to return a const T and that you would have to put the const to the right of the function name to make it const. This topic has come up a number of times, and there are quite a few folks who think that the current situation is flawed. There's certainly no question that it's confusing. Personally, I'd argue that function modifiers should just go on the right of the function, except that that would be confusing with regards to modifiers like private or abstract which other languages put to the left of the function. So, I'd strongly argue that it will cause fewer problems if you had to put immutable and const to the right of the function name to make the function immutable or const. Yes, it's inconsistent with other function modifiers, but it's more consistent with variable declarations and other languages., and it will causes less confusion. The other solution would be to always require parens for const and immutable types regardless of whether they're for return types or variable declarations, but I can't imagine that that would go over very well. In any case, at minimum, the error message needs to be improved. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4571] Non-null class references/pointers
http://d.puremagic.com/issues/show_bug.cgi?id=4571 --- Comment #1 from bearophile_h...@eml.cc 2010-08-26 16:41:58 PDT --- This is just half of a solution. Beside introducing nonnull pointers/references, and a handy syntax to denote them, to have a null-safe language you also need to require explicit tests every time a nullable pointers/references is about to be dereferenced, and then after this test in the else branch the reference type "becomes" a non-nullable one. This is an application of the idea of "TypeState", used by the Mozilla Rust language. The type doesn't actually change, it's just its state that change. More on the concept of TypeState (at the moment it is not present in Wikipedia): http://www.google.com/search?q=typestate -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4625] "in" operator for AAs in SafeD code
http://d.puremagic.com/issues/show_bug.cgi?id=4625 --- Comment #1 from bearophile_h...@eml.cc 2010-08-26 16:58:40 PDT --- See also bug 4475 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4475] Improving the compiler 'in' associative array can return just a bool
http://d.puremagic.com/issues/show_bug.cgi?id=4475 --- Comment #1 from bearophile_h...@eml.cc 2010-08-26 16:59:06 PDT --- See also bug 4625 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 937] C-style variadic functions broken
http://d.puremagic.com/issues/show_bug.cgi?id=937 Dan G. changed: What|Removed |Added CC||ven...@gmail.com --- Comment #3 from Dan G. 2010-08-26 17:26:47 PDT --- While working on GDC, it was found this bug still exists in 1.063. The problem appears to be an if statement in func.c around line 811. "parameters" is not initialized until further down in the function. By substituting "f->parameters" the problem is resolved. --- // Original if statement if (f->linkage == LINKd || (parameters && parameters->dim)) // Modified if statement if (f->linkage == LINKd || (f->parameters && Parameter::dim(f->parameters))) GDC ticket. http://bitbucket.org/goshawk/gdc/issue/57/c-style-variadic-functions-broken -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4571] Non-null class references/pointers
http://d.puremagic.com/issues/show_bug.cgi?id=4571 --- Comment #2 from bearophile_h...@eml.cc 2010-08-26 17:27:34 PDT --- An example implementation of TypeState for Java: http://www.warski.org/blog/?cat=9 http://www.warski.org/typestate.html The original paper about typestates, Typestate: A Programming Language Concept for Enhancing Software Reliability", by Robert E. Strom and Shaula Yemini, 1986: http://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestate.pdf A version for dotnet, Typestates for Objects", by R. DeLine and M. F�hnrich: http://www.cs.cmu.edu/~aldrich/courses/819/slides/typestates.ppt http://research.microsoft.com/apps/pubs/default.aspx?id=67458 The software: http://research.microsoft.com/en-us/projects/fugue/ (But it says Fugue is no longer supported as a tool. However, check out our related project called CodeContracts.") More on the topic: http://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---