[Issue 6431] New: [RDMD] Modifying a library doesn't trigger a rebuild
http://d.puremagic.com/issues/show_bug.cgi?id=6431 Summary: [RDMD] Modifying a library doesn't trigger a rebuild Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: cbkbbej...@mailinator.com --- Comment #0 from Nick Sabalausky 2011-08-02 22:32:54 PDT --- Similar to issue 6102, but for libraries: 1. Build some program with RDMD 2. Modify a static library your program uses. 3. Run RDMD again. RDMD will use the cached executable instead of rebuilding it. I've made this a separate issue because it's more difficult to solve than issue 6102. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6102] [RDMD] Changing a string import file doesn't trigger a rebuild
http://d.puremagic.com/issues/show_bug.cgi?id=6102 --- Comment #3 from Nick Sabalausky 2011-08-02 22:34:06 PDT --- Pull request fixing this issue: https://github.com/D-Programming-Language/tools/pull/6 That fixes the issue for "file" (ie string imports), "binary" and "config". Fixing it for "library" is more difficult since the path to the library has to be figured out (rather than scraped from the deps file), so I've made a separate issue for that: issue 6431 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6102] [RDMD] Changing a string import file doesn't trigger a rebuild
http://d.puremagic.com/issues/show_bug.cgi?id=6102 --- Comment #2 from Nick Sabalausky 2011-08-02 19:41:01 PDT --- The string import files are already in the .deps file, they're just marked "file" instead of "import". (At least in 2.054 anyway.) The .deps entries marked "binary", "config" and "library" should also be checked. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6430] New: Overloaded auto-return functions each with a nested aggregate of the same name are conflated
http://d.puremagic.com/issues/show_bug.cgi?id=6430 Summary: Overloaded auto-return functions each with a nested aggregate of the same name are conflated Product: D Version: D2 Platform: Other OS/Version: Mac OS X Status: NEW Keywords: rejects-valid Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: kenn...@gmail.com --- Comment #0 from kenn...@gmail.com 2011-08-02 13:34:53 PDT --- Test case 1: - auto bug6430(int a) { static struct Result2 {} return 4; } auto bug6430(int a, int b) { static struct Result2 { int z; int y() { return z; } // <-- line 11 } auto t = Result2(1); // <-- line 13 return 5; } - x.d(11): Error: this for z needs to be type Result2 not type Result2 x.d(13): Error: more initializers than fields of Result2 - The same happens if we replace 'static struct' as 'class' or 'union' with or without 'static'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5790] "Error: variable result used before set" when -release -inline -O
http://d.puremagic.com/issues/show_bug.cgi?id=5790 kenn...@gmail.com changed: What|Removed |Added Platform|x86 |All --- Comment #5 from kenn...@gmail.com 2011-08-02 12:50:03 PDT --- Another test case, which is triggered only on Linux and FreeBSD. --- void test5790d() { int x; int y = *(1 + &x); } --- $ dmd -O -c test5790d.d Error: variable x used before set --- See also https://github.com/D-Programming-Language/dmd/pull/243#issuecomment-1706278. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6427] Templated ctor cannot set immutable member variables
http://d.puremagic.com/issues/show_bug.cgi?id=6427 --- Comment #2 from Jonathan M Davis 2011-08-02 12:45:15 PDT --- Okay. It looks like immutable constructors only apply to when the struct or class itself that you're constructing is immutable. So, this should definitely compile. And it does on the current version of the compiler. So, if it doesn't compile on 2.054, then this it was fixed since the release. I'd close it, but we might want it end the changelog, so it's probably better that someone who actually works on the compiler closes the bug. Regardless, it works with the latest version of the compiler, so 2.055 shouldn't have this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4460] Regression(2.036) ICE(e2ir.c) when compiling foreach over associative array literal
http://d.puremagic.com/issues/show_bug.cgi?id=4460 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #10 from Walter Bright 2011-08-02 12:14:41 PDT --- https://github.com/D-Programming-Language/dmd/commit/dd2cf0493ef3e80e36b3f5206b2eac86d337c58b https://github.com/D-Programming-Language/dmd/commit/c09e14ed2a010b38562a416537ba84871bccc577 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6427] Templated ctor cannot set immutable member variables
http://d.puremagic.com/issues/show_bug.cgi?id=6427 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis 2011-08-02 11:06:42 PDT --- 1. This compiles with the current compiler on github. 2. I'm not even 100% sure this is supposed to compile, since the constructor isn't immutable. That might only be necessary when the whole struct is immutable though. I don't remember for sure and would have to check in TDPL (which I don't have on me at the moment). 3. While this should certainly compile correctly based on the language spec (or not compile depending on the spec). I would serious advise against having const or immutable variables in a struct, since you can then never assign to them even if they're not const or immutable. If they're on the heap, it's not as big a deal, but a struct like S would be useless in arrays (since all of the values would be stuck as S.init) and every instance of it would be effectively immutable regardless of whether the object itself was typed as immutable or not. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6428] Inconsistent implement in std.array.replaceFirst
http://d.puremagic.com/issues/show_bug.cgi?id=6428 klickverbot changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #2 from klickverbot 2011-08-02 09:09:19 PDT --- https://github.com/D-Programming-Language/phobos/pull/168 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6429] New: Nested function error in reduce
http://d.puremagic.com/issues/show_bug.cgi?id=6429 Summary: Nested function error in reduce Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2011-08-02 07:27:56 PDT --- import std.algorithm; alias reduce!((a, b){ return 1; }) foo; void main() { foo([1, 2, 3]); } Error: delegate test.__dgliteral1!(int,int).__dgliteral1 is a nested function and cannot be accessed from reduce This will work however: import std.algorithm; void main() { alias reduce!((a, b){ return 1; }) foo; foo([1, 2, 3]); } I can't tell whether this is a bug or something subtle that I don't understand. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6428] Inconsistent implement in std.array.replaceFirst
http://d.puremagic.com/issues/show_bug.cgi?id=6428 --- Comment #1 from Heromyth 2011-08-02 07:01:13 PDT --- I have a patch: --- array.dSun Jul 10 13:19:30 2011 +++ array-new.dTue Aug 02 21:58:12 2011 @@ -1522,7 +1522,7 @@ auto app = appender!R1(); app.put(subject[0 .. subject.length - balance.length]); app.put(to.save); -subject = balance[from.length .. $]; +app.put(balance[from.length .. $]); return app.data; } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6428] New: Inconsistent implement in std.array.replaceFirst
http://d.puremagic.com/issues/show_bug.cgi?id=6428 Summary: Inconsistent implement in std.array.replaceFirst Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bitwo...@qq.com --- Comment #0 from Heromyth 2011-08-02 06:55:12 PDT --- Test code: string s1 = "abc bcf"; string s2 = s1.replaceFirst("bc", "ee"); writefln("%s\n%s", s1, s2); The s2 should be "aee bcf", however the result of replaceFirst is "aee". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4749] Templated & non-templated constructors conflicting
http://d.puremagic.com/issues/show_bug.cgi?id=4749 simendsjo changed: What|Removed |Added CC||simend...@gmail.com --- Comment #4 from simendsjo 2011-08-02 06:46:56 PDT --- A smaller test case: struct S { this()(int v) {} this(char[] v) {} } t.d(3): Error: constructor t.S.this conflicts with template t.S.__ctor() at t.d( 2) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #27 from Kenji Hara 2011-08-02 06:39:43 PDT --- (In reply to comment #26) Thanks for your reply. I have two claims. 1. D language specification already implicitly allow automatic tuple expansion. a) Alias this allows an implicit conversion to aliased symbol. b) We can take tuple symbol (= TupleDeclaration) as aliased symbol. The above two items lead automatic expansion naturally. If you prohibit that, it will make a serious exception to the language specification. Dealing with the tuple expansion by alias this may complicate the implementation of the compiler, but will not introduce an exception of language specification. 2. Tuples are anonymous structures, and itself has no meaning. We should treat tuples as open, not closed. void f1(Point p); // struct Point{ int x, y; } void f2(int n, int m); The parameters of f1 and f2 are fundamentally different. And where Tuple!(int, int) belongs to? I think it is same as parameters of f2. Therefore we need automatically expansion. It seems to me that Tuple is essential feature to a modern language (like a Unix pipe) . And I believe that D is one of the very few languages that can treat it with type-safe. I did mark issues - 2779, 2781, 6366, 6369 as *BUG*. Please think seriously about tuple expansion and alias this. Sorry to my poor English. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6427] New: Templated ctor cannot set immutable member variables
http://d.puremagic.com/issues/show_bug.cgi?id=6427 Summary: Templated ctor cannot set immutable member variables Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: simend...@gmail.com --- Comment #0 from simendsjo 2011-08-02 06:39:49 PDT --- struct S { immutable int v; this()(int v) { this.v = v; } } void main() { S s = S(1); } Error: can only initialize const member v inside constructor Error: template instance t.S.__ctor!(int) error instantiating -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6426] New: Internal error with function-nested alias
http://d.puremagic.com/issues/show_bug.cgi?id=6426 Summary: Internal error with function-nested alias Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: blocker Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2011-08-02 05:47:40 PDT --- DMD 2.054, XP32: import std.algorithm; void main() { alias reduce!((a, b){ return min(a, b); }) rngMin2; auto arr2 = map!(rngMin2)([[1, 2], [1, 2]]); } Internal error: toir.c 190 The code above can be written simpler like below: import std.algorithm; void main() { alias reduce!(min) rngMin; auto arr1 = map!(rngMin)([[1, 2], [1, 2]]); // ok } But that's beside the point. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #26 from Walter Bright 2011-08-02 01:33:48 PDT --- My main reservation about this is not that I can see anything obviously wrong about it, but I am nervous we are building a special case for tuples. I think any expansion of tuple support should be part of a more comprehensive design for tuples. If we grow tuple support by adding piecemeal special cases for this and that, without thinking about them more globally, we are liable to build ourselves into a box we can't get out of. I can give examples in other languages that did this - the most infamous being the great C idea of conflating arrays and pointers. It seems to be a great idea in the small, but only much larger experience showed what a disastrous mistake it was. We should step back and figure out what we want to do with tuples in the much more general case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---