[Issue 3029] Bug in array value mangling rule
http://d.puremagic.com/issues/show_bug.cgi?id=3029 Kosmonaut changed: What|Removed |Added CC||kosmon...@tempinbox.com --- Comment #6 from Kosmonaut 2010-02-05 23:41:50 PST --- (In reply to comment #3) > changeset 370 http://www.dsource.org/projects/dmd/changeset/370 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3450] incorrect result for is (typeof({ ... }())) inside a struct
http://d.puremagic.com/issues/show_bug.cgi?id=3450 Kosmonaut changed: What|Removed |Added CC||kosmon...@tempinbox.com --- Comment #3 from Kosmonaut 2010-02-05 23:39:34 PST --- (In reply to comment #2) > changeset 371 http://www.dsource.org/projects/dmd/changeset/371 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3769] Regression: Segfault(constfold.c) array literals and case statements
http://d.puremagic.com/issues/show_bug.cgi?id=3769 Kosmonaut changed: What|Removed |Added CC||kosmon...@tempinbox.com --- Comment #5 from Kosmonaut 2010-02-05 23:37:43 PST --- (In reply to comment #4) > Changeset 372 http://www.dsource.org/projects/dmd/changeset/372 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3029] Bug in array value mangling rule
http://d.puremagic.com/issues/show_bug.cgi?id=3029 --- Comment #5 from Don 2010-02-05 22:09:00 PST --- (In reply to comment #4) > Why keep the backwards compatibility in D2? Yes. With things like the recent change to ModuleInfo, you can't even update the compiler one revision without recompiling. So I don't think we have to worry about D2 backwards compatibility for the next month (which is why it's crucial to get these types of bugs fixed now). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3769] Regression: Segfault(constfold.c) array literals and case statements
http://d.puremagic.com/issues/show_bug.cgi?id=3769 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright 2010-02-05 20:37:36 PST --- Changeset 372 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3450] incorrect result for is (typeof({ ... }())) inside a struct
http://d.puremagic.com/issues/show_bug.cgi?id=3450 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2010-02-05 19:54:33 PST --- changeset 371 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3029] Bug in array value mangling rule
http://d.puremagic.com/issues/show_bug.cgi?id=3029 Brad Roberts changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #4 from Brad Roberts 2010-02-05 19:33:46 PST --- Why keep the backwards compatibility in D2? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3029] Bug in array value mangling rule
http://d.puremagic.com/issues/show_bug.cgi?id=3029 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright 2010-02-05 19:27:30 PST --- changeset 370 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3775] New: Compiler segfaults on cast(string) stdin.byLine.
http://d.puremagic.com/issues/show_bug.cgi?id=3775 Summary: Compiler segfaults on cast(string) stdin.byLine. Product: D Version: 2.040 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: blood.of.l...@gmail.com --- Comment #0 from Bernard Helyer 2010-02-05 18:36:45 PST --- Apologies if this is a duplicate, I couldn't see anything *obvious*. I'm sure this is invalid code, but I got on to doing this (don't ask): --- module segfault; import std.stdio; void main() { foreach (line; cast(string) stdin.byLine) {} } --- Which leads to: --- $ dmd segfault Segmentation fault --- Needless to say, no object or executable file is produced. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3774] New: should not be able to implicitly cast to private base class
http://d.puremagic.com/issues/show_bug.cgi?id=3774 Summary: should not be able to implicitly cast to private base class Product: D Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bugzi...@digitalmars.com --- Comment #0 from Walter Bright 2010-02-05 18:05:00 PST --- It seems I have been testing this with a buggy c++ compiler or can't remember what was the problem previously. I now tried with gcc 4.4.3 and this is how D and C++ differ: --- class Foo { public: void bar() {} }; class Bar : private Foo { }; int main() { Foo *a = new Bar(); a->bar(); } test.cpp: In function ‘int main()’: test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’ --- module m1; class Foo { public void bar() {} } class Bar : private foo { } module m2; import m1; void main() { Foo a = new Bar(); a.bar(); } // compiles and runs just fine // Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3773] New: Incorrectly returning an enum error points turns enum line iso error line
http://d.puremagic.com/issues/show_bug.cgi?id=3773 Summary: Incorrectly returning an enum error points turns enum line iso error line Product: D Version: 0.155 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: st...@despam.it --- Comment #0 from st...@despam.it 2010-02-05 15:48:14 PST --- -- 1 module test; 2 enum { A = 0, B, C } 3 enum E { A = 0, B, C } 4 void func1(){ 5 return A;} 6 void func2(){ 7 return E.A;} 8 void func3(){ 9 return 0;} -- test.d(2): Error: long has no effect in expression (0) // should point to line 5, very annoying to find this kind of bug! test.d(7): Error: long has no effect in expression (cast(E)0) // correct line but still incomprehensible test.d(9): Error: long has no effect in expression (0) // correct line but say what? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2835] std.socket.TcpSocket.connect doesn't actually connect
http://d.puremagic.com/issues/show_bug.cgi?id=2835 iorlas changed: What|Removed |Added CC||4yb...@gmail.com --- Comment #6 from iorlas 2010-02-05 15:46:27 PST --- *** Issue 3649 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 3649] Socket not configured for work.
http://d.puremagic.com/issues/show_bug.cgi?id=3649 iorlas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #8 from iorlas 2010-02-05 15:46:27 PST --- (In reply to comment #7) > This bug is duplicate of #2835. > > The problem is caused by missing sin.sin_family initialization. > Please apply the fix suggested in bug #2835. Great. Now waiting for fixing in repo... *** This issue has been marked as a duplicate of issue 2835 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3649] Socket not configured for work.
http://d.puremagic.com/issues/show_bug.cgi?id=3649 Andrey changed: What|Removed |Added CC||bigas...@gmail.com --- Comment #7 from Andrey 2010-02-05 15:37:09 PST --- This bug is duplicate of #2835. The problem is caused by missing sin.sin_family initialization. Please apply the fix suggested in bug #2835. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3511] ref return property confused with property setter
http://d.puremagic.com/issues/show_bug.cgi?id=3511 --- Comment #2 from Kyle Foley 2010-02-05 14:30:22 PST --- (In reply to comment #1) > Yes, this is interesting "feature" but I think it should be marked to be so, > be > some kind of attributed: > > > struct A { > private int x_ = 42; > > @property > @ref_getter_as_setter > ref int x() { return x_; } > } > > It still can be allowed without this properties, but then compile should emit > warning. > > What do you think? I think that properties in general suck. The only thing I want is the syntax for omitting the parentheses when calling a function without arguments. I don't want the compiler transforming something like "a.property = 42;" into "a.property(42);". It seems so bizarre to me, but I must be in the minority. I would solve this problem by either introducing reference types like C++ or allowing alias this to alias to a dereferenced pointer: struct Ref(T) { T* _ref; alias *_ref this; this(ref T rhs) { _ref = &rhs; } } Then I could implement properties by doing something like this: struct A { private int _prop = 42; PropertyHelper property() { return PropertyHelper(_prop); } struct PropertyHelper { private int _p; private Ref!int _reference; alias _p this; // aliased to a copy this(ref int rhs) : _reference(rhs); // meh, I don't know how to do this in D { writeln("Log: called the getter"); _p = rhs; // note this is a copy } void opAssign(in int rhs) { writeln("Log: called the setter"); _reference = rhs; } } } But a problem could be that when doing "auto x = a.property;" the type of x would be PropertyHelper. I mean, personally I would just do int getProperty(); and void setProperty(int); and be done with it. Anyways, I think we need to provide more general functionality from the compiler so that cool things can be done with libraries (e.g. letting alias this do more like the example above). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3666] Enhancement Request: Mixin Templates
http://d.puremagic.com/issues/show_bug.cgi?id=3666 Nick Sabalausky changed: What|Removed |Added CC||cbkbbej...@mailinator.com --- Comment #1 from Nick Sabalausky 2010-02-05 13:08:19 PST --- A two-part addendum: 1. As D's CTFE improves, there's been more and more reason to generate a string mixin using CTFE instead of a template. Simen's point that "Most templates that are made to be mixed in, will not be used in any other way" is also true for CTFE functions. So this enhancement request should also be extended to CTFE functions in addition to templates: --- mixin string foo2() { return "int a;"; } foo2(); a = 7; --- 2. It is probably worth noting that this enhancement request can be used to trivially re-implement the current string mixin: --- mixin string mixinString(string str) { return str; } mixinString("int a;"); --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3155] LDC2 support for druntime
http://d.puremagic.com/issues/show_bug.cgi?id=3155 --- Comment #3 from Trass3r 2010-02-05 12:04:44 PST --- Yeah, I think gdc is also gradually approaching 2.020 where druntime was introduced and will face the same problem. They are currently upgrading to 2.016. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3155] LDC2 support for druntime
http://d.puremagic.com/issues/show_bug.cgi?id=3155 --- Comment #2 from Sean Kelly 2010-02-05 11:36:59 PST --- The druntime source tree has changed to the point where it's no longer trivial to integrate an additional compiler runtime. I'll have to think about how to add LDC2 support. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3155] LDC2 support for druntime
http://d.puremagic.com/issues/show_bug.cgi?id=3155 Hoenir changed: What|Removed |Added CC||mrmoc...@gmx.de --- Comment #1 from Hoenir 2010-02-05 09:19:31 PST --- What's the status of this issue, Sean? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3692] Compiler with associative arrays when std.variant is imported
http://d.puremagic.com/issues/show_bug.cgi?id=3692 Don changed: What|Removed |Added Keywords||ice-on-valid-code, patch Severity|normal |regression --- Comment #5 from Don 2010-02-05 06:40:24 PST --- PATCH: mtype.c line 3870 -// Create .AssociativeArray!(index, next) +// Create object.AssociativeArray!(index, next) DotTemplateInstanceExp *dti = new DotTemplateInstanceExp(loc, -new IdentifierExp(loc, Id::empty), +new IdentifierExp(loc, Id::object), Id::AssociativeArray, tiargs); Or possibly it should be .object.AssociativeArray -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 678] Compiler accepts, for a function T[] t(), t().ptr but not t.ptr
http://d.puremagic.com/issues/show_bug.cgi?id=678 Witold Baryluk changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #5 from Witold Baryluk 2010-02-05 06:27:27 PST --- The problem with this code is that compiler doesn't know if you ask for: 1) a pointer of the base of the void[] array returned from t (used as property) 2) or a pointer of the t function/delegatel -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3221] Array extension methods require parentheses
http://d.puremagic.com/issues/show_bug.cgi?id=3221 --- Comment #3 from Witold Baryluk 2010-02-05 06:24:01 PST --- Similary to the bug3771 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3692] Compiler with associative arrays when std.variant is imported
http://d.puremagic.com/issues/show_bug.cgi?id=3692 --- Comment #4 from Don 2010-02-05 06:23:12 PST --- (In reply to comment #3) > Just one additional detail: > > In the program where I noticed this problem for the first time, as suggested > by > others, I worked around the bug by using a copy of std.variant.d with all the > occurrences of "AssociativeArray" replaced with something else. > > I tried going back to std.variant in my program, and the crash was still > there. > In other words, it seems that the bug still has something to do with > identifiers named "AssociativeArray". Yes. Reduced test case: - import file2; void main() { bool[int] a; auto x = a.keys[0]; } --- file2: int AssociativeArray; -- Basically my patch fixed the specific case of bug 3552 but failed in the general case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3771] warn or disallow method as property usage without @property attribute
http://d.puremagic.com/issues/show_bug.cgi?id=3771 --- Comment #1 from Witold Baryluk 2010-02-05 06:23:04 PST --- Similary with array methods without brackets: a.find = b; auto c = a.toUpper; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3772] New: Extension methods
http://d.puremagic.com/issues/show_bug.cgi?id=3772 Summary: Extension methods Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bary...@smp.if.uj.edu.pl --- Comment #0 from Witold Baryluk 2010-02-05 06:20:17 PST --- Long time ago there was a idea to have extending (well this isn't best name) of the class implementations. This is my proposition: == module m1; class A { int x() { retutn 5 } } == module m2; import m1; @extend(A) float y(A a) { return a.x() * 11.1; } @extend(A) @property float z(A a) { return a.y() + 22.1; } module test; import m1, m2; A a = new A(); assert(a.y() == 55.5); assert(a.z == 77.6); == Questoin remains if y(a) is valid function call. This is not necasarly best way becuase it would be best if y, z method will have access to private fields of A. It also should be possible tu use this in them (this can be emulated using with: @extend(A) float y(A this) { with(this) { return x() * 11.1; } } Actually this is similar to my suggested problem with array (and not only) methods. I.e. a.find(b) is transleted to find(a, b). It should be explicitly be written: @extend(string) int find(string a, string b) Othere asspect is interference with the template functions. One can't easly have things like: @extend(T) int something(T)(T a) { return 42; } becuase this method can extend all types. And this is problematic for two reasons: - conflicts of such widely applicable functions. - efficiency of searching for such functions. (but it shouldn't be actually so big problem if this information is cached for each type on first usage). This also makes questionably if it should have such syntax, more appropriate will be nonredudant: @extend_first_argument int something(T)(T a) { return 42; } Other possiblity (AFAIK used in C#, but don't remember exactly, is to use this): int something(this A a) { } or int something(this A this) { } Where first this is indicating that this is extending function. Second this is just convinient name for usage inside of something(A) function (preferably with with, evetntually with(this) should be automatically put there). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3221] Array extension methods require parentheses
http://d.puremagic.com/issues/show_bug.cgi?id=3221 Witold Baryluk changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #2 from Witold Baryluk 2010-02-05 06:22:09 PST --- One should possibly add @property for such function, so it will be possible tu use such function not only as method but also as getter. Unfortunetly it isn't yet implemented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3771] New: warn or disallow method as property usage without @property attribute
http://d.puremagic.com/issues/show_bug.cgi?id=3771 Summary: warn or disallow method as property usage without @property attribute Product: D Version: 2.040 Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bary...@smp.if.uj.edu.pl --- Comment #0 from Witold Baryluk 2010-02-05 06:20:03 PST --- We have now @property and in feature we will have other attributes. It is time to not only have this syntax, but actually do something with this information: - emit warning when using method without call brackets on getter/setter - emit warning when using array methods: a.find(b) == find(a, b) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2853] Property overriding problem
http://d.puremagic.com/issues/show_bug.cgi?id=2853 Witold Baryluk changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #2 from Witold Baryluk 2010-02-05 06:01:31 PST --- Actually setter in the base class is not needed to trigger this bug. Also calling this.number() in method(), so adding call brackets, doesn't solve problem. So it is not only problem with setter/getter. This can lead to problem with perfectly valid code with no properties. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3511] ref return property confused with property setter
http://d.puremagic.com/issues/show_bug.cgi?id=3511 Witold Baryluk changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #1 from Witold Baryluk 2010-02-05 05:46:48 PST --- Yes, this is interesting "feature" but I think it should be marked to be so, be some kind of attributed: struct A { private int x_ = 42; @property @ref_getter_as_setter ref int x() { return x_; } } It still can be allowed without this properties, but then compile should emit warning. What do you think? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3188] remove opIndexAssign from the language
http://d.puremagic.com/issues/show_bug.cgi?id=3188 --- Comment #14 from Witold Baryluk 2010-02-05 05:41:54 PST --- (In reply to comment #11) > (In reply to comment #4) > > (In reply to comment #3) > >> That's one reason. The other reason is that it can do many things that a > >> ref > >> return can't, such as > >> - converting the value to an internal representation > >> - validating the set value > >> - calling some external API to set the value > >> - triggering side effects beyond setting the value in memory > > > > All of these things are doable from a returned struct which contains > > opAssign. > > But it would make code unnecessarily complex, and make the compiler have to > work harder to optimise it to something as well-performing as a simple > opIndexAssign. Well only real problem with opIndexAssign is code duplication and return value of opIndexAssign. But this is easly solved: - duplicated code can be easly moved to private auxilary method used both by opIndex and opIndexAssign - return value can be void if one doesn't want to use chaining (a[2] = a[3] = 5 will be then invalid, becuase (a[3] = 5) have no value). Other solution is to use opIndexAssign for assigment if it is implemented, then try opIndex and check if it returns ref, if yes, perform opIndex + returned ref dereferencing assigment, if both is not possible emit compile error. If automatisation is not good, label opIndex by some kind of property (@implicitIndexAssign ?) > > (In reply to comment #10) > > You are confusing opMul with opStar. > > Yet another reason opStar was the wrong choice of name, besides inconsistency. Bad name indeed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3188] remove opIndexAssign from the language
http://d.puremagic.com/issues/show_bug.cgi?id=3188 --- Comment #13 from Witold Baryluk 2010-02-05 05:36:12 PST --- I again want to say that returning ref is no possible in case of my ussages opIndexAssign. For example I would like to log assigments. Or keep internal caching system. Also it is possible that i have datastructure which needs to know size of the object (string) which i put there, to allocate and rebalance this datastructure. When i would return ref, it would not be possible to perform any such thinkg. Leave opIndexAssign it is very usefull. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #15 from Witold Baryluk 2010-02-05 05:28:30 PST --- (In reply to comment #14) > Exception handling is for error conditions, not flow control. If someone is > actually constructing exceptions for some other purpose then they're using the > wrong tool :-) Well, yes you are right. I just checked my old code which i was thinking is using heavly EH for flow control. But I wasn't so stupid :) EH is only used for escaping in rare ocasions (not for error conditions but for flow control, yes, but i'm comparing more throw here to break; like in for/while, than to continiue :) ) Sorry for the problem. Anyway in documentation of this functionality I think there should be the statment that stacktrace is only intended to help in debuging and crash reporting, and no code should directly depend on the fact that returned backtrace is nonempty or correct. (becuase in one can set traceHandler to null, or disabled it in -release mode for example). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3692] Compiler with associative arrays when std.variant is imported
http://d.puremagic.com/issues/show_bug.cgi?id=3692 --- Comment #3 from Leandro Motta Barros 2010-02-05 04:42:50 PST --- Just one additional detail: In the program where I noticed this problem for the first time, as suggested by others, I worked around the bug by using a copy of std.variant.d with all the occurrences of "AssociativeArray" replaced with something else. I tried going back to std.variant in my program, and the crash was still there. In other words, it seems that the bug still has something to do with identifiers named "AssociativeArray". (That said, this code: void main() { int AssociativeArray; int[int] foo; foreach (x; foo){} } which I took from issue 3552, compiles cleanly here, which seems to indicate that I am *really* running DMD 2.040 here ;-)) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3692] Compiler with associative arrays when std.variant is imported
http://d.puremagic.com/issues/show_bug.cgi?id=3692 Leandro Motta Barros changed: What|Removed |Added Status|RESOLVED|REOPENED Version|2.038 |2.040 Resolution|DUPLICATE | --- Comment #2 from Leandro Motta Barros 2010-02-05 04:18:36 PST --- This bug has been marked as duplicate of issue 3552, so it should supposedly be fixed in DMD 2.040. Unfortunately, it was not. Using DMD 2.040 to compile the same code as before: import std.variant; void main() { bool[int] a; auto x = a.keys[0]; } I get the same compiler crash as before: dmd: mtype.c:3886: StructDeclaration* TypeAArray::getImpl(): Assertion `impl' failed. So, unless I'm doing something very wrong here, I suppose this bug still persists. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3373] bad codeview debug info for long and ulong
http://d.puremagic.com/issues/show_bug.cgi?id=3373 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2010-02-05 02:58:12 PST --- changelog 369 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3769] Regression: Segfault(constfold.c) array literals and case statements
http://d.puremagic.com/issues/show_bug.cgi?id=3769 --- Comment #3 from Don 2010-02-05 02:17:54 PST --- Better test case, works for both D1 and D2: --- const char[][ 89 ] ENUM_NAME = [ 1:"N0" ]; void bug3769() { switch(`Hi`.dup) { case ENUM_NAME[1]: } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3769] Regression: Segfault(constfold.c) array literals and case statements
http://d.puremagic.com/issues/show_bug.cgi?id=3769 Don changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code, patch Summary|Segfault(constfold.c) using |Regression: |invalid case (D1 only) |Segfault(constfold.c) array ||literals and case ||statements --- Comment #2 from Don 2010-02-05 00:12:17 PST --- The root cause is in init.c, Expression *ArrayInitializer::toExpression(), around line 439. The Expressions array which holds all of the members of the array literal, does not get initialized. But the later part of this function assumes that all of the entries are null. Here's a patch which fixes it: elements = new Expressions(); elements->setDim(edim); + elements->zero(); for (size_t i = 0, j = 0; i < value.dim; i++, j++) { if (index.data[i]) j = ((Expression *)index.data[i])->toInteger(); BUT... this kind of bug is ridiculous, IMHO. I think in root/array.c, void Array::reserve(unsigned nentries) should be initializing the data it gets from realloc. I bet this isn't the only place in the compiler where this landmine is waiting. Absolutely horrid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---