[Issue 3769] Regression: Segfault(constfold.c) array literals and case statements
http://d.puremagic.com/issues/show_bug.cgi?id=3769
Don clugd...@yahoo.com.au 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 clugd...@yahoo.com.au 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: ---
[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 clugd...@yahoo.com.au 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 3373] bad codeview debug info for long and ulong
http://d.puremagic.com/issues/show_bug.cgi?id=3373 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 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 3692] Compiler with associative arrays when std.variant is imported
http://d.puremagic.com/issues/show_bug.cgi?id=3692
Leandro Motta Barros l...@stackedboxes.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Version|2.038 |2.040
Resolution|DUPLICATE |
--- Comment #2 from Leandro Motta Barros l...@stackedboxes.org 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 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 l...@stackedboxes.org 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 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 bary...@smp.if.uj.edu.pl 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 3188] remove opIndexAssign from the language
http://d.puremagic.com/issues/show_bug.cgi?id=3188 --- Comment #14 from Witold Baryluk bary...@smp.if.uj.edu.pl 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 3511] ref return property confused with property setter
http://d.puremagic.com/issues/show_bug.cgi?id=3511
Witold Baryluk bary...@smp.if.uj.edu.pl changed:
What|Removed |Added
CC||bary...@smp.if.uj.edu.pl
--- Comment #1 from Witold Baryluk bary...@smp.if.uj.edu.pl 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 2853] Property overriding problem
http://d.puremagic.com/issues/show_bug.cgi?id=2853 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #2 from Witold Baryluk bary...@smp.if.uj.edu.pl 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 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 bary...@smp.if.uj.edu.pl 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 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 bary...@smp.if.uj.edu.pl 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 3221] Array extension methods require parentheses
http://d.puremagic.com/issues/show_bug.cgi?id=3221 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #2 from Witold Baryluk bary...@smp.if.uj.edu.pl 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 3692] Compiler with associative arrays when std.variant is imported
http://d.puremagic.com/issues/show_bug.cgi?id=3692
--- Comment #4 from Don clugd...@yahoo.com.au 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 3221] Array extension methods require parentheses
http://d.puremagic.com/issues/show_bug.cgi?id=3221 --- Comment #3 from Witold Baryluk bary...@smp.if.uj.edu.pl 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 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||ice-on-valid-code, patch Severity|normal |regression --- Comment #5 from Don clugd...@yahoo.com.au 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 3155] LDC2 support for druntime
http://d.puremagic.com/issues/show_bug.cgi?id=3155 --- Comment #3 from Trass3r mrmoc...@gmx.de 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 3666] Enhancement Request: Mixin Templates
http://d.puremagic.com/issues/show_bug.cgi?id=3666
Nick Sabalausky cbkbbej...@mailinator.com changed:
What|Removed |Added
CC||cbkbbej...@mailinator.com
--- Comment #1 from Nick Sabalausky cbkbbej...@mailinator.com 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 3511] ref return property confused with property setter
http://d.puremagic.com/issues/show_bug.cgi?id=3511
--- Comment #2 from Kyle Foley k-fo...@onu.edu 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 3649] Socket not configured for work.
http://d.puremagic.com/issues/show_bug.cgi?id=3649 Andrey bigas...@gmail.com changed: What|Removed |Added CC||bigas...@gmail.com --- Comment #7 from Andrey bigas...@gmail.com 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 3649] Socket not configured for work.
http://d.puremagic.com/issues/show_bug.cgi?id=3649 iorlas denis.tomi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #8 from iorlas denis.tomi...@gmail.com 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 2835] std.socket.TcpSocket.connect doesn't actually connect
http://d.puremagic.com/issues/show_bug.cgi?id=2835 iorlas denis.tomi...@gmail.com changed: What|Removed |Added CC||4yb...@gmail.com --- Comment #6 from iorlas denis.tomi...@gmail.com 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 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 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 bugzi...@digitalmars.com 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 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 blood.of.l...@gmail.com 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 3029] Bug in array value mangling rule
http://d.puremagic.com/issues/show_bug.cgi?id=3029 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright bugzi...@digitalmars.com 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 3029] Bug in array value mangling rule
http://d.puremagic.com/issues/show_bug.cgi?id=3029 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #4 from Brad Roberts bra...@puremagic.com 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 --- Comment #5 from Don clugd...@yahoo.com.au 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 Kosmonaut kosmon...@tempinbox.com changed: What|Removed |Added CC||kosmon...@tempinbox.com --- Comment #5 from Kosmonaut kosmon...@tempinbox.com 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: ---
