[Issue 4931] New: Implicit opCast!bool in if statement doesn't work with declarator
http://d.puremagic.com/issues/show_bug.cgi?id=4931
Summary: Implicit opCast!bool in if statement doesn't work with
declarator
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro 2010-09-23 20:49:09 PDT
---
Created an attachment (id=772)
Patch against dmd r686
If an if statement has a variable declarator, a condition is implicitly
converted to bool before its value is assigned to the declared variable. The
following code doesn't compile:
void main()
{
if (S s = S()) {} // (3)
}
struct S
{
bool opCast(T : bool)() { return true; }
}
% dmd -o- -c test.d
test.d(3): Error: cannot implicitly convert expression (S().opCast()) of type
bool to S
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4930] New: [patch] RDMD: Cmd line sent to dmd can be too long
http://d.puremagic.com/issues/show_bug.cgi?id=4930 Summary: [patch] RDMD: Cmd line sent to dmd can be too long Product: D Version: D1 & D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: cbkbbej...@mailinator.com --- Comment #0 from Nick Sabalausky 2010-09-23 20:32:42 PDT --- Created an attachment (id=771) Patch against rdmd r1400 If rdmd is compiling a program that has a lot of dependencies, such as ddmd, the command line sent to dmd can get too big for the shell/OS to handle, and compilation will not occur. The attached patch makes rdmd send args to dmd in a response file if the list of files gets too large. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3848] functions in std.file don't take symbolic links into account
http://d.puremagic.com/issues/show_bug.cgi?id=3848 Jonathan M Davis changed: What|Removed |Added Attachment #705 is|0 |1 obsolete|| --- Comment #20 from Jonathan M Davis 2010-09-23 20:13:21 PDT --- Created an attachment (id=770) Changes based off of phobos revision 2046 Here's the full file with my changes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3848] functions in std.file don't take symbolic links into account
http://d.puremagic.com/issues/show_bug.cgi?id=3848 Jonathan M Davis changed: What|Removed |Added Attachment #706 is|0 |1 obsolete|| --- Comment #19 from Jonathan M Davis 2010-09-23 20:12:14 PDT --- Created an attachment (id=769) Patch with changes based off of phobos revision 2046 Okay, I've updated the patch for dmd 2.049 (the diff is off of phobos svn r2046, but there aren't any changes between 2.049 and r2046). I also added a test for bug #4929, which this patch fixes without any new changes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4929] New: DirEntry does not always report correct type of file on linux
http://d.puremagic.com/issues/show_bug.cgi?id=4929
Summary: DirEntry does not always report correct type of file
on linux
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis 2010-09-23 19:57:31
PDT ---
Okay, if you run this program
import std.file;
import std.stdio;
void main()
{
foreach(DirEntry dentry; dirEntries("/usr/share/zoneinfo", SpanMode.depth))
{
if(dentry.isfile)
writefln("file: %s", dentry.name);
else if(dentry.isdir)
writefln("dir: %s", dentry.name);
else
writefln("other: %s", dentry.name);
}
}
on a Linux box, you get this output (or something very close to it):
other: /usr/share/zoneinfo/GB
other: /usr/share/zoneinfo/NZ
other: /usr/share/zoneinfo/US
other: /usr/share/zoneinfo/CET
other: /usr/share/zoneinfo/EET
other: /usr/share/zoneinfo/EST
other: /usr/share/zoneinfo/GMT
other: /usr/share/zoneinfo/HST
other: /usr/share/zoneinfo/Etc
other: /usr/share/zoneinfo/MET
other: /usr/share/zoneinfo/MST
other: /usr/share/zoneinfo/PRC
other: /usr/share/zoneinfo/ROC
other: /usr/share/zoneinfo/ROK
other: /usr/share/zoneinfo/UCT
other: /usr/share/zoneinfo/UTC
other: /usr/share/zoneinfo/WET
other: /usr/share/zoneinfo/Asia
other: /usr/share/zoneinfo/Cuba
other: /usr/share/zoneinfo/GMT0
other: /usr/share/zoneinfo/Eire
other: /usr/share/zoneinfo/Iran
other: /usr/share/zoneinfo/W-SU
other: /usr/share/zoneinfo/Arctic
other: /usr/share/zoneinfo/Zulu
other: /usr/share/zoneinfo/Canada
other: /usr/share/zoneinfo/Brazil
other: /usr/share/zoneinfo/America
other: /usr/share/zoneinfo/Universal
other: /usr/share/zoneinfo/Europe
other: /usr/share/zoneinfo/Pacific
other: /usr/share/zoneinfo/Iceland
other: /usr/share/zoneinfo/iso3166.tab
other: /usr/share/zoneinfo/Chile
other: /usr/share/zoneinfo/GMT+0
other: /usr/share/zoneinfo/GMT-0
other: /usr/share/zoneinfo/Egypt
other: /usr/share/zoneinfo/Japan
other: /usr/share/zoneinfo/Portugal
other: /usr/share/zoneinfo/Libya
other: /usr/share/zoneinfo/Indian
other: /usr/share/zoneinfo/Israel
other: /usr/share/zoneinfo/posix
other: /usr/share/zoneinfo/right
other: /usr/share/zoneinfo/Hongkong
other: /usr/share/zoneinfo/Mexico
other: /usr/share/zoneinfo/Navajo
other: /usr/share/zoneinfo/Poland
other: /usr/share/zoneinfo/Jamaica
other: /usr/share/zoneinfo/EST5EDT
other: /usr/share/zoneinfo/Turkey
other: /usr/share/zoneinfo/GB-Eire
other: /usr/share/zoneinfo/zone.tab
other: /usr/share/zoneinfo/Antarctica
other: /usr/share/zoneinfo/Australia
other: /usr/share/zoneinfo/Kwajalein
other: /usr/share/zoneinfo/MST7MDT
other: /usr/share/zoneinfo/Singapore
other: /usr/share/zoneinfo/posixrules
other: /usr/share/zoneinfo/NZ-CHAT
other: /usr/share/zoneinfo/Factory
other: /usr/share/zoneinfo/Atlantic
other: /usr/share/zoneinfo/Greenwich
other: /usr/share/zoneinfo/Mideast
other: /usr/share/zoneinfo/PST8PDT
other: /usr/share/zoneinfo/CST6CDT
other: /usr/share/zoneinfo/Africa
Note that all of these files are in fact either directories or regular files. I
don't really know why, but my guess is that d_type is used from the
core.sys.posix.dirent.dirent for the file, and it deosn't work on all file
systems. I've tried it on 3 machines, with two different distros. All used
reiserfs for the / partition, so all of those were on reieserfs, and all
failed. I also tried it on one of my machienes by copying /usr/share/zoneinfo
onto my /home partition which uses jfs. It failed there too. Other directories
and files work just fine, so I don't know what's so special about zoneinfo.
It should be noted, however, that if you use std.isfile() or std.isdir(), it
works just fine - probably because those use stat.
I don't have a specific patch for this bug, but my patch for bug# 3848 does
apparently fix this bug (probably because it doesn't use d_type if it's
DT_UNKNOWN but instead uses stat in that case).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4928] [patch] RDMD mistakes object, library and response files for the program file.
http://d.puremagic.com/issues/show_bug.cgi?id=4928 --- Comment #2 from Nick Sabalausky 2010-09-23 18:33:13 PDT --- Ditto for ".def" files. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4928] [patch] RDMD mistakes object, library and response files for the program file.
http://d.puremagic.com/issues/show_bug.cgi?id=4928 --- Comment #1 from Nick Sabalausky 2010-09-23 18:31:31 PDT --- Note that problem also occurs if "extraStuff.obj" is a ".o", ".lib", ".a", or "@extraStuff.txt". The patch fixes all of these cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4923] immutable module variables are modifiable in non-shared module constructors
http://d.puremagic.com/issues/show_bug.cgi?id=4923 --- Comment #2 from Kasumi Hanazuki 2010-09-23 18:25:30 PDT --- I have no idea whether the spec states immutable module variables to be allocated per thread or not, but currently DMD places them as shared and there seems no way to store them in TLS. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4928] New: [patch] RDMD mistakes object, library and response files for the program file.
http://d.puremagic.com/issues/show_bug.cgi?id=4928 Summary: [patch] RDMD mistakes object, library and response files for the program file. Product: D Version: D1 & D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: cbkbbej...@mailinator.com --- Comment #0 from Nick Sabalausky 2010-09-23 18:29:20 PDT --- Created an attachment (id=768) Patch against rdmd r1400 > rdmd extraStuff.obj main.d Expected: chdir "." && dmd extraStuff.obj -v -o- "main.d" >main.d.deps Actual: chdir "." && dmd -v -o- "extraStuff.obj.d" >extraStuff.obj.d.deps -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4927] writefln silently ignores arguments not present in the format string
http://d.puremagic.com/issues/show_bug.cgi?id=4927 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4923] immutable module variables are modifiable in non-shared module constructors
http://d.puremagic.com/issues/show_bug.cgi?id=4923 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #1 from nfx...@gmail.com 2010-09-23 16:04:20 PDT --- Isn't this by design? Immutable variables are per-thread, and normal module constructors are used to initialize per-thread data. You need a way to initialize immutable variables. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4458] Static typing for format strings, when possible
http://d.puremagic.com/issues/show_bug.cgi?id=4458 --- Comment #1 from bearophile_h...@eml.cc 2010-09-23 15:34:27 PDT --- See also bug 4927 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4927] New: writefln silently ignores arguments not present in the format string
http://d.puremagic.com/issues/show_bug.cgi?id=4927
Summary: writefln silently ignores arguments not present in the
format string
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-09-23 15:33:40 PDT ---
With dmd 2.049 this program:
import std.stdio: writefln;
void main() {
writefln("%d", 1, 2);
}
Prints:
1
But in this case I expect a compile-time error (or equivalent run-time error if
the compiler is lazy and doesn't perform such very basic tests at
compile-time), because the format string doesn't contain the same things as the
given arguments.
In this case printing 12 is not good, because when a writefln is used, it's
better to avoid possible bugs to enforce that arguments and format string match
exactly.
See also bug 4458
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4921] Synopsis code in std.variant documentation throws an assertion error
http://d.puremagic.com/issues/show_bug.cgi?id=4921 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4922] don't work readf with char, wchar and dchar
http://d.puremagic.com/issues/show_bug.cgi?id=4922 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4926] ICE: PREC_zero assertion failure due to unset precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4926 --- Comment #1 from Shin Fujishiro 2010-09-23 14:01:53 PDT --- *** Issue 4912 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 4912] ICE [expToCBuffer] compile-time access to non-existent AA member
http://d.puremagic.com/issues/show_bug.cgi?id=4912 Shin Fujishiro changed: What|Removed |Added Keywords|patch | Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Shin Fujishiro 2010-09-23 14:01:53 PDT --- *** This issue has been marked as a duplicate of issue 4926 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4926] New: ICE: PREC_zero assertion failure due to unset precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4926
Summary: ICE: PREC_zero assertion failure due to unset
precedence
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro 2010-09-23 13:54:58 PDT
---
Created an attachment (id=767)
Patch against dmd r685, sets missing precedences
Precedences for the following TOKs are not set, while they can be referenced by
expToCBuffer().
TOKassocarrayliteral, TOKcomplex80, TOKdelegate, TOKdotexp,
TOKdottype, TOKdsymbol, TOKfile, TOKhalt, TOKline,
TOKnewanonclass, TOKoverloadset, TOKremove, TOKtemplate.
This causes PREC_zero assertion failures in expToCBuffer(). The following cases
all trigger the assertion failure.
template Q(s...) { alias s q; }
class C {}
enum assocarrayliteral = Q!( [1:2] ).q.stringof;
enum complex80 = Q!( 1+1.0i ).q.stringof;
enum dottype = Q!( C.Object.toString ).q.stringof;
enum halt = (assert(0), 0).stringof;// ICE w/ -release
enum remove = Q!( [1:2].remove(1) ).q.stringof;
enum templat = Q!( Q ).q.stringof;
The halt case depends on bug 4925. dottype and remove are ice-on-invalid.
Although I couldn't find any offending case for the other TOKs, I think it's
better to define reasonable precedences for all the said TOKs.
The attached patch also fixes bug 4912 and bug 4914.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4925] New: [ICE] segfault with module-scope assert(0)
http://d.puremagic.com/issues/show_bug.cgi?id=4925
Summary: [ICE] segfault with module-scope assert(0)
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice-on-valid-code, patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro 2010-09-23 13:34:12 PDT
---
The following code crashes the compiler:
const int a = (assert(0), 1);
Patch:
--- src/expression.c
+++ src/expression.c
@@ -5695,8 +5695,11 @@ Expression *AssertExp::semantic(Scope *sc)
}
if (e1->isBool(FALSE))
{
-FuncDeclaration *fd = sc->parent->isFuncDeclaration();
-fd->hasReturnExp |= 4;
+if (sc->parent && sc->parent->isFuncDeclaration())
+{
+FuncDeclaration *fd = sc->parent->isFuncDeclaration();
+fd->hasReturnExp |= 4;
+}
if (!global.params.useAssert)
{ Expression *e = new HaltExp(loc);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #12 from Stewart Gordon 2010-09-23 13:23:32 PDT --- (In reply to comment #11) > In D there are several precedents, this is a bug in D only: > for (i = 0; i < 10; i++); It isn't a bug, it's illegal code. A bug is something different. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #11 from bearophile_h...@eml.cc 2010-09-23 13:11:30 PDT --- Jonathan M Davis: >The grammar is totally unambiguous.< For a computer. But people aren't that precise. The syntax of a computer language is not designed for the computer, it's designed to be an interface for the very bug-prone apes that use the computer. >I can't see Walter ever agreeing to make it an error.< In D there are several precedents, this is a bug in D only: for (i = 0; i < 10; i++); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #10 from Jonathan M Davis 2010-09-23 13:00:50 PDT --- Except that this case is a classic case in computer programming with a clear and standard solution. The grammar is totally unambiguous. I can't see Walter ever agreeing to make it an error. No other language that I'm aware of does. A warning makes some sense. An error does not. Granted, Walter doesn't like warnings, but that doesn't mean that there's no way that he's going to add it, and there's always the possibility that another D compiler down the road would flag it as a warning. Just because Walter wouldn't want to make it a warning in dmd doesn't mean that it should become an error. If it's a question of error or nothing, I'm strongly behind nothing, and my guess is that Walter will be as well. I'm fine with it becoming a warning, but an error is too strong. The language is quite clear on the matter. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4924] Suspect indentation warning
http://d.puremagic.com/issues/show_bug.cgi?id=4924 --- Comment #1 from bearophile_h...@eml.cc 2010-09-23 12:33:50 PDT --- Sorry, my mistake, I meant see also bug 4375 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4924] New: Suspect indentation warning
http://d.puremagic.com/issues/show_bug.cgi?id=4924
Summary: Suspect indentation warning
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-09-23 12:26:40 PDT ---
Unlike Python, Haskell, F# and few other languages, line indentations in D
don't determine the semantics of the program. Yet programmers are humans, they
do make mistakes, and for them indentations have meaning and importance (this
is why good programmers usually indent their code carefully). A badly indented
code doesn't just look sloppy, it may hide semantic problems.
To reduce the noise it's important to minimize false positives, so the D
compiler may issue warnings (errors are too much) only in few specific
situations where a bad indentation is a clue of a possible semantic bug, and
ignore indentations in all other situations.
A situation that may justify a warning, an unexpected positive indentation
after a single-line then/else/for/foreach/while:
if (x > 5)
a = 1;
b = 2; // suspect indentation warning
if (y > 2)
c = 3;
else
d = 4;
e = 5; // suspect indentation warning
for (int i = 0; i < 10; i++)
f++;
g++; // suspect indentation warning
foreach (j; 0 .. 10)
h++;
j++; // suspect indentation warning
while (x < 10)
x = foo(x);
y++; // suspect indentation warning
if (x > 5)
a = 1; b = 2; // no warning here?
if (x > 5)
a = 1;
b = 2; // no warning here
if (x > 5) a = 1; b = 2; // no warning here
This simple warning is able to catch some common bugs (just as requiring {}
instead of just a semicolon avoids other similar bugs).
See also bug 4357
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #9 from bearophile_h...@eml.cc 2010-09-23 12:27:44 PDT --- Stewart Gordon: > to be an error, rather than to be parsed in one of the two possible > ways, doesn't require the compiler to understand indentation at all. Right, for this enhancement request the indentation is irrelevant. See bug 4924 for something about indentation. > If it were made an error, it wouldn't be a mere suggestion, surely? It is meant first of all as an error. Jonathan M Davis: > It's the kind of thing that you add to a compiler as you're trying to > find incremental improvements to add to a compiler that is essentially > already complete (like gcc). That's true if you are talking about a warning. But Walter doesn't like warnings, and I think in this case a true error is acceptable. And if it's an error, then it's part of the language, so you can't perform this change too much late. In Bugzilla I have some other very small changes like this one that are hard to do later. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4923] New: immutable module variables are modifiable in non-shared module constructors
http://d.puremagic.com/issues/show_bug.cgi?id=4923
Summary: immutable module variables are modifiable in
non-shared module constructors
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hanaz...@gmail.com
--- Comment #0 from Kasumi Hanazuki 2010-09-23 12:05:20
PDT ---
DMD v2.049 on Windows
immutable module variables, whose instances are thread-global, are modifiable
in thread-local module constructors (static this).
Following example prints different numbers on each iteration.
import core.thread, std.random, std.stdio;
immutable int x;
static this() {
x = unpredictableSeed;
}
void main() {
for(;;) {
(new Thread({ })).start;
Thread.sleep(1_000_000_0);
writeln(x);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4919] dmd test driver fails with EBADF
http://d.puremagic.com/issues/show_bug.cgi?id=4919 Brad Roberts changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||FIXED --- Comment #1 from Brad Roberts 2010-09-23 11:46:08 PDT --- Odd that I don't see the same problem, but either way, that change has been checked in. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4922] New: don't work readf with char, wchar and dchar
http://d.puremagic.com/issues/show_bug.cgi?id=4922
Summary: don't work readf with char, wchar and dchar
Product: D
Version: D2
Platform: x86
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: canalpaycif...@gmail.com
CC: acehr...@yahoo.com
--- Comment #0 from Can Alpay �ift�i 2010-09-23
11:28:15 PDT ---
Code:
import std.stdio;
void main() {
char a;
wchar b;
dchar c;
readf("%s %s %s", &a,&b,&c);
}
Error :
dmd -w -c "isimsiz.d" (C:\Program Files\Geany )
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(441): Error: template
std.format.unformatValue(T,Range,Char) if (isArray!(T) && !isSomeString!(T))
does not match any function template declaration
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(441): Error: template
std.format.unformatValue(T,Range,Char) if (isArray!(T) && !isSomeString!(T))
cannot deduce template function from argument types
!(char)(LockingTextReader,FormatSpec!(char))
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(441): Error: template
instance errors instantiating template
Please note that this works:
int i;
readf("%s", &i);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4784] [ICE] with count()
http://d.puremagic.com/issues/show_bug.cgi?id=4784
osa8...@gmail.com changed:
What|Removed |Added
CC||osa8...@gmail.com
--- Comment #1 from osa8...@gmail.com 2010-09-23 09:53:16 PDT ---
I got the same ICE (dmd 2.048 on linux) and was able to reduce the problem to a
small test case which does not involve any libraries like std.algorithm:
struct A( alias P ) {
static void a() {
void aa() { P(); }
}
}
template B( alias P ) {
void b() { A!P a; }
}
struct C( alias P ) {
void c() { B!P.b(); }
}
void main() {
void bar() {}
C!bar c;
}
Compiling this produces the same error:
Internal error: toir.c 190
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #8 from Jonathan M Davis 2010-09-23 09:53:57 PDT --- I think what Bearophile wants is that in cases where the grammar (and thus the compiler) use the typical dangling else rule to determine that the last else goes with the last if that the compiler should flag it as a warning, on the theory that the programmer probably screwed up. Apparently there are other compilers - including gcc - which flag such as a warning. OF course, most competent programmers would likely have braces around multiple levels of if anyway, thus totally avoiding the issue, but if the programmer doesn't do that, then they can end up with the last else going with an if they didn't intend because they really meant to use braces or perhaps accidentally deleted the if that went with the else (since there could be several lines between the last if and the else and the grammar still sees them as part of the same if statement). Since other compilers such as gcc flag this sort of thing as a warning, requiring braces to get rid of it, I guess that there's some value in having it be a warning in dmd. However, since I don't think that it's terribly responsible to even code in the way that you have to code to get the issue to show up, I don't think that it's particularly worth having. Still, it wouldn't hurt anyone who was coding more intelligently, since they'd never see the warning anyway. There's enough value to the enhancement that it may get implemented at some point, but it would be low enough priority that it's probably going to sit in the queue for a very long time if it ever gets implemented. It's the kind of thing that you add to a compiler as you're trying to find incremental improvements to add to a compiler that is essentially already complete (like gcc). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4921] New: Synopsis code in std.variant documentation does throw an assertion error
http://d.puremagic.com/issues/show_bug.cgi?id=4921 Summary: Synopsis code in std.variant documentation does throw an assertion error Product: D Version: D2 Platform: x86 OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: daniel.kullm...@gmx.net --- Comment #0 from Daniel Kullmann 2010-09-23 07:49:51 PDT --- Created an attachment (id=766) Fix for bug When running the code from the synopsis in the documentation for std.variant, it throws an assertion error, because one of the asserts is the wrong way round. Attached a patch that also makes the Synopsis code a complete program -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3735] op=
http://d.puremagic.com/issues/show_bug.cgi?id=3735
Stewart Gordon changed:
What|Removed |Added
Keywords||rejects-valid
URL||http://www.digitalmars.com/
||d/1.0/expression.html
CC||s...@iname.com
Platform|Other |All
Version|2.038 |D1 & D2
OS/Version|Linux |All
--- Comment #1 from Stewart Gordon 2010-09-23 06:16:30 PDT ---
I assume you're talking about the fact that code like this fails:
--
class Qwert {
Qwert opAdd(Qwert yuiop) { return this; }
}
void main() {
Qwert asfdg = new Qwert;
asdfg += asdfg;
}
--
I entirely agree that this code should work, on the bases both of common sense
and of this spec.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375 --- Comment #7 from Stewart Gordon 2010-09-23 06:03:28 PDT --- (In reply to comment #0) > So in D2 I propose to turn that code into an actual syntax error, similar to > using the warnings-as-errors option of GCC: > ...>gcc -Wall -Werror test.c -o test > cc1.exe: warnings being treated as errors > test.c: In function 'main': > test.c:6:8: error: suggest explicit braces to avoid ambiguous 'else' If it were made an error, it wouldn't be a mere suggestion, surely? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375
Stewart Gordon changed:
What|Removed |Added
CC||s...@iname.com
--- Comment #6 from Stewart Gordon 2010-09-23 05:59:44 PDT ---
(In reply to comment #1)
> Except that then you have to make the compiler understand
> indentation.
??? Defining the form
if ( IfCondition ) if ( IfCondition ) ThenStatement else ElseStatement
to be an error, rather than to be parsed in one of the two possible
ways, doesn't require the compiler to understand indentation at all.
> Requiring it to be able to understand indentation well enough to
> alert the programmer as to where they used it incorrectly or to
> complain that the programmer has used it in a manner which could be
> ambiguous to a human reader would likely complicate things quite a
> bit for the compiler.
But if you design the language to be whitespace- and indent-sensitive
in the first place, then it's easy. That's how Python has managed
it. You need a different type of parser to read the language, but it
isn't difficult.
On the other hand, you can't add indent-sensitivity to a free-form
language, unless you discard the free-form aspect and require line
breaks in set places. But then it would be silly to require curly
brackets and semicolons, which is why Python doesn't. This would be
a huge breaking change for D were it to be implemented.
> Also, it could be rather nasty to code generators, since then
> they'd have to worry a lot more about making code human-readable -
> which while potentially nice probably isn't necessary in many cases.
ISTM code generators would likely put the {} in, because it's easier
to program it to always put them in than to detect whether they're
necessary.
> I believe that the usual solution if a programmer is worried about
> this sort of thing is just to use a coding standard that always
> requires braces for the bodies of if-else statements, loops, etc.
My personal style is to always use {} unless the whole IfStatement or
similar fits on one line. Though I do use "else if" rather than
else {
if (...) {
...
}
}
and I've been known to do things like
else switch (...) {
...
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4920] New: Member expression tuple allowed for types, disallowed for expressions
http://d.puremagic.com/issues/show_bug.cgi?id=4920
Summary: Member expression tuple allowed for types, disallowed
for expressions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro 2010-09-23 03:18:28 PDT
---
Created an attachment (id=765)
Patch against dmd r680
Alias to a non-type tuple can't be used as a member of struct or class. The
following code doesn't compile.
struct Test(parameters_...)
{
alias parameters_ parameters;
}
Test!(10, 20, 30) test;
static assert(typeof(test).parameters[1] == 20); // okay
static assert( test .parameters[1] == 20); // (7)
% dmd -o- -c test.d
test.d(7): Error: 10 is not a member
test.d(7): Error: static assert ((__error) == (__error)) is false
DotVarExp::semantic() only allows tuple of member variables as a member. The
proposed patch changes it so that other kinds of tuples are allowed. Passed
dmd/druntime/phobos tests.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4919] New: dmd test driver fails with EBADF
http://d.puremagic.com/issues/show_bug.cgi?id=4919 Summary: dmd test driver fails with EBADF Product: D Version: D2 Platform: x86 OS/Version: Linux Status: NEW Keywords: patch, rejects-valid Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: rsi...@gmail.com --- Comment #0 from Shin Fujishiro 2010-09-23 01:46:01 PDT --- Running the dmd tests on Gentoo 2.6.32 fails with an unexpected EBADF. dmd/test$ make (== snip ==) ... runnable/bench1.d -d (-inline -release -gc -O -unittest -fPIC) sh: 1: Bad file descriptor Test failed. The logged output: (== snip ==) The problem is the test driver. It issues "test_results/runnable/bench1 1> " to the shell, in which the "1>" part is wrong. Patch: --- test/d_do_test.d +++ test/d_do_test.d @@ -204,7 +204,7 @@ void execute(ref File f, string command, bool expectpass) scope(exit) if (std.file.exists(filename)) std.file.remove(filename); f.writeln(command); -auto rc = system(command ~ "> " ~ filename ~ " 2>&1"); +auto rc = system(command ~ " > " ~ filename ~ " 2>&1"); f.write(readText(filename)); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4918] New: tuples in eponymous template have default values only
http://d.puremagic.com/issues/show_bug.cgi?id=4918
Summary: tuples in eponymous template have default values only
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 2010-09-23 01:10:49
PDT ---
This code
import std.stdio;
import std.typecons;
template mytemp(T...)
{
static if(T.length == 1)
enum mytemp = tuple(T[0]);
else
enum mytemp = tuple(T[0], mytemp!(T[1..$]).expand);
}
void main()
{
writeln(mytemp!(5));
writeln(mytemp!(5, 10, 7));
writeln(mytemp!(true));
writeln(mytemp!(true, false, true));
writeln(mytemp!("hello"));
writeln(mytemp!("hello", "world"));
}
results in this output
Tuple!(int)(0)
Tuple!(int,int,int)(0, 0, 0)
Tuple!(bool)(false)
Tuple!(bool,bool,bool)(false, false, false)
Tuple!(string)()
Tuple!(string,string)(, )
If I change it to
import std.stdio;
import std.typecons;
template mytemp(T...)
{
enum mytemp = T[0];
}
void main()
{
writeln(mytemp!(5));
writeln(mytemp!(true));
writeln(mytemp!("hello"));
}
I get
5
true
hello
So obviously, there's something wrong with tuple here. And it's pretty
crippling for my current project actually.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4424] Copy constructor and templated opAssign cannot coexist
http://d.puremagic.com/issues/show_bug.cgi?id=4424
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #2 from Don 2010-09-23 00:09:42 PDT ---
Don't have a full patch yet, but this is where the problem is.
clone.c, StructDeclaration::buildOpAssign().
Parameter *param = new Parameter(STCnodtor, type, Id::p, NULL);
Parameters *fparams = new Parameters;
fparams->push(param);
Type *ftype = new TypeFunction(fparams, handle, FALSE, LINKd);
#if STRUCTTHISREF
((TypeFunction *)ftype)->isref = 1;
#endif
fop = new FuncDeclaration(0, 0, Id::assign, STCundefined, ftype);
+ Dsymbol *s = search_function(this, Id::assign);
+ TemplateDeclaration *td = s ? s->isTemplateDeclaration() : NULL;
+ if (td)
+ { // we need to make a template function instead
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
