[Issue 8656] New: Different naming of member base/next in TypeInfo_Const in object_.d and object.di
http://d.puremagic.com/issues/show_bug.cgi?id=8656
Summary: Different naming of member base/next in TypeInfo_Const
in object_.d and object.di
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze 2012-09-14 01:02:12
PDT ---
In object_.d, the name of the modified type in TypeInfo_Const is called "base",
while in object.di, the declaration looks like this:
class TypeInfo_Const : TypeInfo
{
TypeInfo next;
}
This forces you to use different namings depending on whether you compile with
druntime or something else. I recommend naming it "base" as all other TypeInfo
declarations do.
TypeInfo_Const in object.di even shadows the next() property of TypeInfo that
returns something else. Unfortunately the next field already seems to be used
in phobos, so it has to be changed there aswell.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8657] New: TypeInfo generated for const/immutable static arrays not transitive
http://d.puremagic.com/issues/show_bug.cgi?id=8657
Summary: TypeInfo generated for const/immutable static arrays
not transitive
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze 2012-09-14 01:29:37
PDT ---
This test program
import std.stdio;
void test(T)()
{
T p;
writeln("==");
writeln("p: ", typeid(p));
TypeInfo ti = typeid(p);
TypeInfo_Const cti = cast(TypeInfo_Const)ti;
writeln("p[0] : ", typeid(p[0]));
writeln("ti.next : ", cast(TypeInfo)ti.next); // cannot write
const(TypeInfo)
writeln("cti.base : ", cti.next);
}
void testMod(T)()
{
test!(const(T))();
test!(immutable(T))();
test!(shared(T))();
}
void main()
{
testMod!(int*)();
testMod!(int[])();
testMod!(int[2])();
//testMod!(int[2][3])();
}
outputs:
==
p: const(const(int)*)
p[0] : const(int)
ti.next : const(int)
cti.base : const(int)*
==
p: immutable(immutable(int)*)
p[0] : immutable(int)
ti.next : immutable(int)
cti.base : immutable(int)*
==
p: shared(shared(int)*)
p[0] : shared(int)
ti.next : shared(int)
cti.base : shared(int)*
==
p: const(const(int)[])
p[0] : const(int)
ti.next : const(int)
cti.base : const(int)[]
==
p: immutable(immutable(int)[])
p[0] : immutable(int)
ti.next : immutable(int)
cti.base : immutable(int)[]
==
p: shared(shared(int)[])
p[0] : shared(int)
ti.next : shared(int)
cti.base : shared(int)[]
==
p: const(int[2])
p[0] : const(int)
ti.next : int
cti.base : int[2]
==
p: immutable(int[2])
p[0] : immutable(int)
ti.next : int
cti.base : int[2]
==
p: shared(shared(int)[2])
p[0] : shared(int)
ti.next : shared(int)
cti.base : shared(int)[2]
It shows that the next and base properties of the TypeInfo generated for
const(int[2]) and immutable(int[2]) lose the qualifier. This does not happen
for "shared".
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8658] New: Passing large structs to function b value causes stack corruption
http://d.puremagic.com/issues/show_bug.cgi?id=8658
Summary: Passing large structs to function b value causes stack
corruption
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze 2012-09-14 01:41:33
PDT ---
If the arguments passed to a function exceed 64kB the stack gets corrupted.
Compiling and running this code without optimizations leads to a crash:
struct S
{
int[16385] a;
}
void foo(S s)
{
}
void main()
{
S s;
for(int i = 0; i < 100; i++)
foo(s);
}
This is caused by the frame pointer cleanup only popping the lower 16 bit of
the used stack size:
_D4test3fooFS4test1SZv comdat
assume CS:_D4test3fooFS4test1SZv
ret 4
_D4test3fooFS4test1SZv ends
[Actually I never meant to do this, it happened because I thought I was passing
a class reference.]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7752] Static array .init is actually .init of the array element type, not the array.
http://d.puremagic.com/issues/show_bug.cgi?id=7752
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2012-09-14 03:12:46 PDT ---
Just executed this:
void main() // 1
{ // 2
int[5] x; // 3
// 4
if (x == x.init) { } // 5 Code that should be legal
if (x.init == x[0].init) { } // 6 Code that is actually illegal
} // 7
And it produces:
main.d(6): Error: incompatible types for (([0,0,0,0,0]) == (0)): 'int[5u]' and
'int'
So it looks like the issue is fixed. Anybody know which pull fixed this, or
should I just close?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8659] New: CTFE: str ~= wchar rejected if string was initialized with an array literal
http://d.puremagic.com/issues/show_bug.cgi?id=8659
Summary: CTFE: str ~= wchar rejected if string was initialized
with an array literal
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2012-09-14 03:39:55 PDT ---
This was the second bug reported in bug 8601. It's completely unrelated to the
first one. A string initialized with an array literal doesn't
support ~= of a character of a larger size.
bool bug()
{
string r = ['x', 'q'];
dchar c = '�';
r ~= c;
assert(r == "xq�");
return true;
}
static assert(bug());
bug.d(8): Error: Cannot interpret r ~= c at compile time
I'm not entirely sure what to do with this. The problem is, after r~=c, is r a
string literal or an array literal?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8660] New: Unclear semantics of array literals of char type, vs string literals
http://d.puremagic.com/issues/show_bug.cgi?id=8660
Summary: Unclear semantics of array literals of char type, vs
string literals
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2012-09-14 04:28:17 PDT ---
Array literals of char type, have completely different semantics from string
literals. In module scope:
char[] x = ['a']; // OK -- array literals can have an implicit .dup
char[] y = "b";// illegal
A second difference is that string literals have a trailing \0. It's important
for compatibility with C, but is barely mentioned in the spec. The spec does
not state if the trailing \0 is still present after operations like
concatenation.
CTFE can use either, but it has to choose one. This leads to odd effects:
string foo(bool b) {
string c = ['a'];
string d = "a";
if (b)
return c ~ c;
else
return c ~ d;
}
char[] x = foo(true); // ok
char[] y = foo(false); // rejected!
This is really bizarre because at run time, there is no difference between
foo(true) and foo(false). They both return a slice of something allocated on
the heap. I think x = foo(true) should be rejected as well, it has an implicit
cast from immutable to mutable.
I think the best way to clean up this mess would be to convert char[] array
literals into string literals whenever possible. This would mean that string
literals may occasionally be of *mutable* type! This would means that whenever
they are assigned to a mutable variable, an implicit .dup gets added (just as
happens now with array literals). The trailing zero would not be duped.
ie:
A string literal of mutable type should behaves the way a char[] array literal
behaves now.
A char[] array literal of immutable type should behave the way a string literal
does now.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8598] [regression 2.059] Calling template function doesn't print instantiated line number
http://d.puremagic.com/issues/show_bug.cgi?id=8598 Don changed: What|Removed |Added Status|RESOLVED|REOPENED CC||clugd...@yahoo.com.au Resolution|FIXED | --- Comment #4 from Don 2012-09-14 04:43:35 PDT --- This isn't merged into D1 yet. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 8660] New: Unclear semantics of array literals of char type, vs string literals
On Friday, 14 September 2012 at 11:28:04 UTC, Don wrote:
--- Comment #0 from Don 2012-09-14
04:28:17 PDT ---
Array literals of char type, have completely different
semantics from string
literals. In module scope:
char[] x = ['a']; // OK -- array literals can have an implicit
.dup
char[] y = "b";// illegal
A second difference is that string literals have a trailing \0.
It's important
for compatibility with C, but is barely mentioned in the spec.
The spec does
not state if the trailing \0 is still present after operations
like
concatenation.
I think this is the normal behavior actually. When you write
"char[] x = ['a'];", you are not actually "newing" (or "dup"-ing)
any data. You are just letting x point to a stack allocated array
of chars. So the assignment is legal (but kind of unsafe
actually, if you ever leak x).
On the other hand, you can't bind y to an array of immutable
chars, as that would subvert the type system.
This, on the other hand, is legal.
char[] y = "b".dup;
I do not know how to initialize a char[] on the stack though
(Appart from writing ['h', 'e', 'l', ... ]). If utf8 also gets
involved, then I don't know of any workaround.
I think a good solution would be to request the "m" prefix for
literals, which would initialize them as "mutable":
x = m"some mutable string";
A second difference is that string literals have a trailing \0.
It's important
for compatibility with C, but is barely mentioned in the spec.
The spec does
not state if the trailing \0 is still present after operations
like
concatenation.
CTFE can use either, but it has to choose one. This leads to
odd effects:
string foo(bool b) {
string c = ['a'];
string d = "a";
if (b)
return c ~ c;
else
return c ~ d;
}
char[] x = foo(true); // ok
char[] y = foo(false); // rejected!
This is really bizarre because at run time, there is no
difference between
foo(true) and foo(false). They both return a slice of something
allocated on
the heap. I think x = foo(true) should be rejected as well, it
has an implicit
cast from immutable to mutable.
Good point. For anybody reading though, the actual code example
should be
enum char[] x = foo(true); // ok
enum char[] y = foo(false); // rejected!
I think the best way to clean up this mess would be to convert
char[] array
literals into string literals whenever possible. This would
mean that string
literals may occasionally be of *mutable* type! This would
means that whenever
they are assigned to a mutable variable, an implicit .dup gets
added (just as
happens now with array literals). The trailing zero would not
be duped.
ie:
A string literal of mutable type should behaves the way a
char[] array literal
behaves now.
A char[] array literal of immutable type should behave the way
a string literal
does now.
I think this would work with my "m" suggestion
[Issue 8661] New: typeof not an attribute, doesn't work with UFCS
http://d.puremagic.com/issues/show_bug.cgi?id=8661
Summary: typeof not an attribute, doesn't work with UFCS
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2012-09-14 05:57:31 PDT ---
In the title: Because "typeof" is a keyword,it does not have the same semantics
as the other properties (http://dlang.org/property.html), such as stringof,
sizeof etc..
For example:
void main()
{
int a;
writeln(int.stringof);
writeln(a.typeof.stringof); //This
writeln(typeof(a).stringof);
}
The syntax "a.typeof.stringof" should be made to work.
UFCS should not have a different behavior because typeof is a keyword.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8201] Conversion from dynamic array to static array fails when static array is immutable
http://d.puremagic.com/issues/show_bug.cgi?id=8201 --- Comment #4 from github-bugzi...@puremagic.com 2012-09-14 06:22:13 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/da8e2a038105ad0149a8f66fbcfe31079ce3a534 fix Issue 8201 - Conversion from dynamic array to static array fails when static array is immutable https://github.com/D-Programming-Language/dmd/commit/ff32f4256e2863f63628f54f43187a8c83c4f8de Merge pull request #1109 from 9rnsr/fix8201 Issue 8201 - Conversion from dynamic array to static array fails when static array is immutable -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 8660] New: Unclear semantics of array literals of char type, vs string literals
On 14/09/12 14:50, monarch_dodra wrote:
On Friday, 14 September 2012 at 11:28:04 UTC, Don wrote:
--- Comment #0 from Don 2012-09-14 04:28:17
PDT ---
Array literals of char type, have completely different semantics from
string
literals. In module scope:
char[] x = ['a']; // OK -- array literals can have an implicit .dup
char[] y = "b";// illegal
A second difference is that string literals have a trailing \0. It's
important
for compatibility with C, but is barely mentioned in the spec. The
spec does
not state if the trailing \0 is still present after operations like
concatenation.
I think this is the normal behavior actually. When you write "char[] x =
['a'];", you are not actually "newing" (or "dup"-ing) any data. You are
just letting x point to a stack allocated array of chars.
I don't think you've looked at the compiler source code...
The dup is in e2ir.c:4820.
So the
assignment is legal (but kind of unsafe actually, if you ever leak x).
Yes it's legal. In my view it is a design mistake in the language.
The issue now is how to minimize the damage from it.
On the other hand, you can't bind y to an array of immutable chars, as
that would subvert the type system.
This, on the other hand, is legal.
char[] y = "b".dup;
I do not know how to initialize a char[] on the stack though (Appart
from writing ['h', 'e', 'l', ... ]). If utf8 also gets involved, then I
don't know of any workaround.
I think a good solution would be to request the "m" prefix for literals,
which would initialize them as "mutable":
x = m"some mutable string";
A second difference is that string literals have a trailing \0. It's
important
for compatibility with C, but is barely mentioned in the spec. The
spec does
not state if the trailing \0 is still present after operations like
concatenation.
CTFE can use either, but it has to choose one. This leads to odd effects:
string foo(bool b) {
string c = ['a'];
string d = "a";
if (b)
return c ~ c;
else
return c ~ d;
}
char[] x = foo(true); // ok
char[] y = foo(false); // rejected!
This is really bizarre because at run time, there is no difference
between
foo(true) and foo(false). They both return a slice of something
allocated on
the heap. I think x = foo(true) should be rejected as well, it has an
implicit
cast from immutable to mutable.
Good point. For anybody reading though, the actual code example should be
enum char[] x = foo(true); // ok
enum char[] y = foo(false); // rejected!
No it should not.
The code example was correct. These are static variables.
I think the best way to clean up this mess would be to convert char[]
array
literals into string literals whenever possible. This would mean that
string
literals may occasionally be of *mutable* type! This would means that
whenever
they are assigned to a mutable variable, an implicit .dup gets added
(just as
happens now with array literals). The trailing zero would not be duped.
ie:
A string literal of mutable type should behaves the way a char[] array
literal
behaves now.
A char[] array literal of immutable type should behave the way a
string literal
does now.
I think this would work with my "m" suggestion
Not necessary. This is only a question about what happens with the
compiler internals.
Re: [Issue 8660] New: Unclear semantics of array literals of char type, vs string literals
On Friday, 14 September 2012 at 15:00:29 UTC, Don Clugston wrote: On 14/09/12 14:50, monarch_dodra wrote: On Friday, 14 September 2012 at 11:28:04 UTC, Don wrote: --- Comment #0 from Don 2012-09-14 04:28:17 PDT --- Array literals of char type, have completely different semantics from string literals. In module scope: char[] x = ['a']; // OK -- array literals can have an implicit .dup char[] y = "b";// illegal A second difference is that string literals have a trailing \0. It's important for compatibility with C, but is barely mentioned in the spec. The spec does not state if the trailing \0 is still present after operations like concatenation. I think this is the normal behavior actually. When you write "char[] x = ['a'];", you are not actually "newing" (or "dup"-ing) any data. You are just letting x point to a stack allocated array of chars. I don't think you've looked at the compiler source code... The dup is in e2ir.c:4820. So the assignment is legal (but kind of unsafe actually, if you ever leak x). Yes it's legal. In my view it is a design mistake in the language. The issue now is how to minimize the damage from it. Thank you for taking the time to educate me. I still have a bit of trouble with static vs dynamic array initializations: Things don't work quite as in C++, which is confusing me. I'll need to study a bit harder how array initializations work. Good news is I'm learning. I think ALL my comments were wrong. In that case, you are right, since: char[] x = "a".dup; Is legal. Good point. For anybody reading though, the actual code example should be enum char[] x = foo(true); // ok enum char[] y = foo(false); // rejected! No it should not. The code example was correct. These are static variables. I hadn't thought of static variables: I placed your code in a main, and both produced a compilation error. The enums reproduced the issue for me however. I think this would work with my "m" suggestion Not necessary. This is only a question about what happens with the compiler internals. Yes.
[Issue 8661] typeof not an attribute, doesn't work with UFCS
http://d.puremagic.com/issues/show_bug.cgi?id=8661 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis 2012-09-14 08:32:51 PDT --- typeof isn't a function, nor is it a property. It's a built-in construct like is-expressions are. Would you want is-expressions to work with UFCS as well? No, I think that this is trying to take UFCS too far. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8660] Unclear semantics of array literals of char type, vs string literals
http://d.puremagic.com/issues/show_bug.cgi?id=8660 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #1 from timon.g...@gmx.ch 2012-09-14 08:42:57 PDT --- I don't have a deep understanding of the DMD CTFE engine, but wouldn't it suffice to do a conversion to a string literal if the type is immutable(char)[] and to an array literal otherwise? This would only have to be done once (recursively on the entire return value) as a final sanitizing step after the CTFE execution has run to completion. This would make both lines illegal, as you suggest. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8658] Passing large structs to function b value causes stack corruption
http://d.puremagic.com/issues/show_bug.cgi?id=8658 Maxim Fomin changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #1 from Maxim Fomin 2012-09-14 09:19:36 PDT --- (In reply to comment #0) > If the arguments passed to a function exceed 64kB the stack gets corrupted. > Compiling and running this code without optimizations leads to a crash: > Couple of comments: 1) This program doesn't crash in x64 linux 2) what exactly is requested: you allocate data on stack which certainly big enough to corrupt it, so? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8658] Passing large structs to function b value causes stack corruption
http://d.puremagic.com/issues/show_bug.cgi?id=8658 Rainer Schuetze changed: What|Removed |Added Platform|All |x86 OS/Version|All |Windows --- Comment #2 from Rainer Schuetze 2012-09-14 09:28:26 PDT --- Sorry, I didn't specify the platform: Windows 32-bit. I don't know if it happens elsewhere. What happens in the example is that each call pushes 16385 words onto the stack, but only 1 gets popped. For x64, the code might be different and the stack might be larger. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8661] typeof not an attribute, doesn't work with UFCS
http://d.puremagic.com/issues/show_bug.cgi?id=8661 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2012-09-14 09:54:18 PDT --- (In reply to comment #1) > typeof isn't a function, nor is it a property. It's a built-in construct like > is-expressions are. Would you want is-expressions to work with UFCS as well? > > No, I think that this is trying to take UFCS too far. See my Issue 4272 I think "a.typeof" is a nice syntax to have, similar to "a.sizeof". But this isn't an example of UFCS. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8661] typeof not an attribute, doesn't work with UFCS
http://d.puremagic.com/issues/show_bug.cgi?id=8661 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from monarchdo...@gmail.com 2012-09-14 11:17:23 PDT --- Yeah... I should have opened it as ER, not Bug. You are right, "nice to have". I searched if it existed before, but did not find your issue. Closing as duplicate. *** This issue has been marked as a duplicate of issue 4272 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4272] x.typeof syntax
http://d.puremagic.com/issues/show_bug.cgi?id=4272 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com 2012-09-14 11:17:24 PDT --- *** Issue 8661 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 4272] x.typeof syntax
http://d.puremagic.com/issues/show_bug.cgi?id=4272 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #3 from Jonathan M Davis 2012-09-14 14:20:26 PDT --- typeof isn't a property or a function, unlike sizeof. It's like an is-expression, and I think that treating it like a property would be a mistake. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 8661] typeof not an attribute, doesn't work with UFCS
Why is this taking it too far? In the duplicate you also expressed reservations about it without explaining why it's a bad idea. UFCS seems very much like the natural evolution of D's syntax and once (if) that's accepted it should be as consistent and general as possible.
