[Issue 4964] New: casting to undefined types crash dmd
http://d.puremagic.com/issues/show_bug.cgi?id=4964
Summary: casting to undefined types crash dmd
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 s...@extrawurst.org 2010-10-01 00:27:41 PDT
---
int main(string[] argv)
{
auto crash = cast(Foo*)_addr;
return 0;
}
yes both Foo and _addr are undefined and dmd issues errors for that but then it
sill crashes with an assert:
main.d(22): Error: identifier 'Foo' is not defined
main.d(22): Error: Foo is used as a type
Assertion failure: 'tn-mod MODimmutable || tn-mod MODconst' on line 875
in file 'mtype.c'
Tested on windows using dmd2.049
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4965] New: Lacking int, uint etc. versions of most std.math functions
http://d.puremagic.com/issues/show_bug.cgi?id=4965 Summary: Lacking int, uint etc. versions of most std.math functions Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: peter.alexander...@gmail.com --- Comment #0 from Peter Alexander peter.alexander...@gmail.com 2010-10-01 01:01:23 PDT --- I noticed that sqrt(int), sqrt(uint) etc. were added to std.math in DMD 2.049 so that you don't have to cast to float or real to calculate simple things like sqrt(2). Is there any reason why integer versions haven't been added for other math functions, like all the trig functions, the exp/log family etc.? These would be useful for the very same reason, and inconsistency isn't very good for library usability. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4965] Lacking int, uint etc. versions of most std.math functions
http://d.puremagic.com/issues/show_bug.cgi?id=4965 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4960] dmd 2.049 rejects code containing templates with a uint as template parameter
http://d.puremagic.com/issues/show_bug.cgi?id=4960 --- Comment #3 from captainsi...@web.de 2010-10-01 02:00:22 PDT --- I agree, your issue sounds similar, but in contrast to your code where there might be a slight difference between the types because the template takes an uint and you instantiate it with an int literal, my example uses uints exclusively and the parameter dimension is typed as an uint. So, there should be no reason for ambiguity... I just tested your programs and they compiled with dmd 2.049... Whereas changing austins example to using int doesn't lead to an compiling program... Essentially I don't get what's going wrong now... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4965] Lacking int, uint etc. versions of most std.math functions
http://d.puremagic.com/issues/show_bug.cgi?id=4965 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2010-10-01 03:11:46 PDT --- (In reply to comment #0) I noticed that sqrt(int), sqrt(uint) etc. were added to std.math in DMD 2.049 so that you don't have to cast to float or real to calculate simple things like sqrt(2). Is there any reason why integer versions haven't been added for other math functions, like all the trig functions, the exp/log family etc.? These would be useful for the very same reason, and inconsistency isn't very good for library usability. Yes, there is a very good reason. It's a dreadful hack. This is the reason why I was extremely strongly opposed to those overloads being added to std.math. They will have to be removed eventually. Essentially, they are hack for the fact that integer literals don't implicitly convert to double. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4966] New: Loops and closures break immutable
http://d.puremagic.com/issues/show_bug.cgi?id=4966
Summary: Loops and closures break immutable
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
--- Comment #0 from nfx...@gmail.com 2010-10-01 03:42:16 PDT ---
Closures referencing immutable variables declared inside a loop can observe how
these immutable values are changing - this should be impossible according to
the definition of immutable.
$ cat closure.d
import std.stdio;
void main() {
void delegate() res;
foreach (i; 0..2) {
immutable v = i;
void printi() {
writefln(ptr=%x value=%d, v , v);
}
if (i == 0) {
res = printi;
res();
}
}
res();
}
$ dmd closure.d
$ ./closure
ptr=b75bae44 value=0
ptr=b75bae44 value=1
As you can see, an immutable variable changed its value. The code above is
SafeD clean, i.e. doesn't use any dirty tricks that would subvert the
typesystem. (Except printing the pointer address, which is just for
demonstrating that it's the same value.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4965] Lacking int, uint etc. versions of most std.math functions
http://d.puremagic.com/issues/show_bug.cgi?id=4965 --- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2010-10-01 05:17:33 PDT --- (In reply to comment #1) Essentially, they are hack for the fact that integer literals don't implicitly convert to double. Aside from labelling it as a hack (which is personal opinion), what is your problem with it i.e. does it actually cause any problems, or have any negative side effects? Normally, a hack is something that is done for short-term convenience but introduces long-term problems (or problems that only occur in rare situations). I fail to see any problems introduced by allowing integer arguments to these functions, yet there is obviously a benefit to doing so (convenience). If people want to call these functions with integers then I see no reason to force them to tediously cast to real or float all the time. D is supposed to be a highly expressive language, and needless casts hurt expressiveness. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4965] Lacking int, uint etc. versions of most std.math functions
http://d.puremagic.com/issues/show_bug.cgi?id=4965 --- Comment #3 from Don clugd...@yahoo.com.au 2010-10-01 05:44:29 PDT --- (In reply to comment #2) (In reply to comment #1) Essentially, they are hack for the fact that integer literals don't implicitly convert to double. Aside from labelling it as a hack (which is personal opinion), what is your problem with it i.e. does it actually cause any problems, or have any negative side effects? Normally, a hack is something that is done for short-term convenience but introduces long-term problems (or problems that only occur in rare situations). I fail to see any problems introduced by allowing integer arguments to these functions Have you seen the code in std.math? It is a really foul hack. If you have a function with 3 arguments, you need to write more than 1000 function overloads. I'm not kidding. Worst code bloat I've seen in my life. The reason why this problem with sqrt arose, is that originally, we only had real sqrt(real), and everything was fine. Then, for reasons I don't understand, overloads for float sqrt(float) and double sqrt(double) were added. Once those were added, integer arguments failed to work. The correct solution at this stage of the language would have been to remove those essentially useless overloads until the language can support them properly. The only place they make any difference is when there is type inference involved. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4967] New: { } struct literals not documented, and not working
http://d.puremagic.com/issues/show_bug.cgi?id=4967
Summary: { } struct literals not documented, and not working
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ah0801...@yahoo.com
--- Comment #0 from Austin Hastings ah0801...@yahoo.com 2010-10-01 06:24:48
PDT ---
I unthinkingly created a struct literal like S s = { 9 }; and it worked (which,
now that I'm complaining about it, I can't find documented in the chm).
But this format doesn't appear to initialize any other fields:
$ cat test.d
import std.stdio;
struct S {
int key;
int x = 1;
void dump() {
writefln(%s %s, key, x);
}
}
void main() {
S s1;
s1.dump;
S s2 = { 9 };
s2.dump;
}
This code prints:
$ dmd -run test.d
0 1
9 1310436
Note the trash in the second variable. I am not sure what the correct solution
is - should struct literals require ctor style, or use static-initializer
format and an implicit copy? - but I would certainly have appreciated a
warning, if nothing else, when I started compiling code like this.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4967] { } struct literals not documented, and not working
http://d.puremagic.com/issues/show_bug.cgi?id=4967 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com Version|D2 |D1 --- Comment #1 from nfx...@gmail.com 2010-10-01 06:45:29 PDT --- They're deprecated in D2. I think D1 has them documented. Maybe should mark this as INVALID. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4967] { } struct literals not documented, and not working
http://d.puremagic.com/issues/show_bug.cgi?id=4967 --- Comment #2 from Austin Hastings ah0801...@yahoo.com 2010-10-01 07:31:35 PDT --- If they're deprecated in D2 but present in D1, why is this now a D1 ticket? The problem (for me) is with D2. If they're deprecated, etc., then all the more reason for dmd2 to issue a warning. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4967] { } struct literals not documented, and not working
http://d.puremagic.com/issues/show_bug.cgi?id=4967 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Version|D1 |D1 D2 --- Comment #3 from Don clugd...@yahoo.com.au 2010-10-01 07:37:57 PDT --- (In reply to comment #1) They're deprecated in D2. I hope that will happen, but so far it hasn't. They are still in the spec. I think D1 has them documented. Maybe should mark this as INVALID. They are documented in D2, in struct.html. It says: The static initializer syntax can also be used to initialize non-static variables, provided that the member names are not given. The initializer need not be evaluatable at compile time. But in DMD, ever since CTFE was introduced, it must be evaluatable at compile time. The implementation is also full of bugs. For example, see bug 3271. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4965] Lacking int, uint etc. versions of most std.math functions
http://d.puremagic.com/issues/show_bug.cgi?id=4965 --- Comment #4 from Peter Alexander peter.alexander...@gmail.com 2010-10-01 09:30:26 PDT --- (In reply to comment #3) Have you seen the code in std.math? It is a really foul hack. If you have a function with 3 arguments, you need to write more than 1000 function overloads. I'm not kidding. Worst code bloat I've seen in my life. Surely constrained templates can help here? I agree that the way they were added was a mess, but that's not an argument for not having them at all (unless it was the only way). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4623] Non-integer type allowed as static array size
http://d.puremagic.com/issues/show_bug.cgi?id=4623 --- Comment #5 from Iain Buclaw ibuc...@ubuntu.com 2010-10-01 11:18:20 PDT --- I haven't ran dstress using the DMD compiler. I think I stumbled upon the case somewhere from an archived message on the ML that probably got forgotten about. I wouldn't go as far as saying all compiler ICE bugs are fixed just yet (I raised an issue recently with CTFE with a patch supplied, for example), though they certainly are very far and few between now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4968] New: inout is sticky to function return type
http://d.puremagic.com/issues/show_bug.cgi?id=4968
Summary: inout is sticky to function return type
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tomash.brec...@gmail.com
--- Comment #0 from Tomash Brechko tomash.brec...@gmail.com 2010-10-01
14:57:27 PDT ---
Call to writeln(f(i)) below won't compile because dmd 2.049 thinks f() returns
inout(int), so void writeln(T...)(T args) expands to void
writeln(inout(int)...(inout(int) args), and inout parameter requires inout
return type. Rewriting void as inout(void) helps, but obviously is wrong.
import std.stdio;
inout(int)
f(inout int i)
{
return i;
}
void
main()
{
int i;
writeln(typeof(f(i)).stringof); // Outputs inout(int), not int.
int j = f(i);
writeln(i); // Works OK :).
writeln(f(i)); // Won't compile :(.
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 620] Can't use property syntax with a template function
http://d.puremagic.com/issues/show_bug.cgi?id=620 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #1 from Simen Kjaeraas simen.kja...@gmail.com 2010-10-01 15:25:37 PDT --- Could we please get this one fixed? Especially now with opDispatch, this is a painful one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4407] Catch wrong argument-attribute assignments in methods
http://d.puremagic.com/issues/show_bug.cgi?id=4407
--- Comment #3 from bearophile_h...@eml.cc 2010-10-01 16:57:39 PDT ---
Another similar class of bugs, suggested by JimBob:
class Foo {
int m_x;
this(int x) {
int m_x = x;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: [Issue 4623] Non-integer type allowed as static array size
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=4623 --- Comment #5 from Iain Buclaw ibuc...@ubuntu.com 2010-10-01 11:18:20 PDT --- I haven't ran dstress using the DMD compiler. I think I stumbled upon the case somewhere from an archived message on the ML that probably got forgotten about. Ah, OK. I wouldn't go as far as saying all compiler ICE bugs are fixed just yet (I raised an issue recently with CTFE with a patch supplied, for example), though they certainly are very far and few between now. I was only referring to the ICE bugs in dstress.
[Issue 4969] New: nothrow check can't handle multiple catches
http://d.puremagic.com/issues/show_bug.cgi?id=4969
Summary: nothrow check can't handle multiple catches
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2010-10-01 20:55:33
PDT ---
This code should compile:
class MyException : Exception
{
this()
{
super(An exception!);
}
}
void throwAway()
{
throw new MyException;
}
void cantthrow() nothrow
{
try
throwAway();
catch(MyException me)
assert(0);
catch(Exception e)
assert(0);
}
void main()
{
}
It doesn't. Instead, you get this error:
d.d(14): Error: function d.cantthrow 'cantthrow' is nothrow yet may throw
If you remove catch(MyException e) and its body, then the program compiles.
Given that the catch block that catches MyException cannot throw an exception
of its own and that the catch block following it catches Exception (and
therefore will catch all exceptions) and cannot throw an exception, the
compiler should be able to clearly determine that no exception can escape
cantthrow, but apparently, it can't.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4970] New: Failed template instantiations need to propogate
http://d.puremagic.com/issues/show_bug.cgi?id=4970
Summary: Failed template instantiations need to propogate
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2010-10-01 22:50:15
PDT ---
Take this program:
import std.conv;
import std.stdio;
void main()
{
dchar[7] numStr = 1234567;
writeln(to!long(numStr));
}
It fails to compile, giving this error:
/home/jmdavis/Downloaded_Files/dmd/dmd2/linux/bin/../../src/phobos/std/conv.d(95):
Error: template std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T)
isSomeString!(T) isInputRange!(Unqual!(S)) isSomeChar!(ElementType!(S)))
toImpl(T,S) if (!implicitlyConverts!(S,T) isSomeString!(T)
isInputRange!(Unqual!(S)) isSomeChar!(ElementType!(S))) matches more than
one template declaration,
/home/jmdavis/Downloaded_Files/dmd/dmd2/linux/bin/../../src/phobos/std/conv.d(217):toImpl(T,S)
if (isStaticArray!(S)) and
/home/jmdavis/Downloaded_Files/dmd/dmd2/linux/bin/../../src/phobos/std/conv.d(588):toImpl(T,S)
if ((is(S : const(wchar)[]) || is(S : const(dchar)[])) !isSomeString!(T))
From the looks of it, the template instantiation has failed due to failing a
template constraint. Looking at std.conv, it looks like the problem is that the
template constraint for toImpl!() fails inside of the template to!(). The error
is given for the instantiation point of toImpl!() inside of to!(). However,
where it needs to be in order to be useful is inside of main(). Granted, adding
a template constraint to to!() would put the error in the correct place, but
really, ideally, dmd would list each of the template instatiations which is
failing here.
Given the code in main(), toImpl!() fails. Listing that is fine. But that means
that to!() fails and the compiler doesn't say a thing about that. It gives the
line in to!(), but you have no way of knowing what code was trying to
instantiate to!(), so you have no idea where the error is. If the error were
simply inside a function, then it's understandable that the error would be
there rather than in the caller, but it's a template function, so the error is
likely in the caller, not the function itself - and in this case, it is.
I would expect that the compiler would be able to realize that it's the middle
of instantiating a chain of templates and thus be able to report an error for
each of them, indicating the instantation failure rather than just the last
one, which buried in code that isn't being called or instantiated directly by
the programmer, which is a pretty useless error all things considered.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Documentation bug.
I downloaded DMD 2.049, which is the latest version available. I tried to write a program using std.thread (incorrectly documented to exist at http://www.digitalmars.com/d/2.0/phobos/std_thread.html), only to find that module thread is in file 'std\thread.d' which cannot be read. Further investigation revealed that the distribution of Phobos included in DMD 2.049 HAS NO FILE NAMED THREAD.D! After more investigation (which revealed that D 1.0 has std.thread), I noticed that the link to std.thread on the Digital Mars web site had the heading core.thread, and fixed my program. It would have saved me a lot of trouble if the link was also named core.thread, instead of having the misleading title (and URL) that suggests that the module's name is std.thread. -- Microsoft Windows. The joke that kills.
[Issue 4971] New: to!() fails with static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=4971
Summary: to!() fails with static arrays
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2010-10-01 22:54:00
PDT ---
This code fails to compile
import std.conv;
import std.stdio;
void main()
{
dchar[7] numStr = 1234567;
writeln(to!long(numStr));
}
with this error
/home/jmdavis/Downloaded_Files/dmd/dmd2/linux/bin/../../src/phobos/std/conv.d(95):
Error: template std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T)
isSomeString!(T) isInputRange!(Unqual!(S)) isSomeChar!(ElementType!(S)))
toImpl(T,S) if (!implicitlyConverts!(S,T) isSomeString!(T)
isInputRange!(Unqual!(S)) isSomeChar!(ElementType!(S))) matches more than
one template declaration,
/home/jmdavis/Downloaded_Files/dmd/dmd2/linux/bin/../../src/phobos/std/conv.d(217):toImpl(T,S)
if (isStaticArray!(S)) and
/home/jmdavis/Downloaded_Files/dmd/dmd2/linux/bin/../../src/phobos/std/conv.d(588):toImpl(T,S)
if ((is(S : const(wchar)[]) || is(S : const(dchar)[])) !isSomeString!(T))
If you use numStr[] instead of numStr, it works. But I see no reason why to!()
can't be made to work with a static array. Ideally, it would either turn it
into a const ref or a dynamic slice itself, thus avoiding creating a copy, but
right now it just fails. Maybe that's just how things go with static arrays,
but it seems overly restrictive in this case. to!() shouldn't _need_ a
dynamically allocated array.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
