[Issue 6452] New: RDMD shouldn't put the compiler in the rsp file
http://d.puremagic.com/issues/show_bug.cgi?id=6452 Summary: RDMD shouldn't put the compiler in the rsp file Product: D Version: unspecified Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@me.com --- Comment #0 from Jacob Carlborg d...@me.com 2011-08-08 01:38:56 PDT --- When the command line exceeds 1024 characters RDMD will use an rsp file, which should only contain flags for the compiler. But RDMD puts the actual compiler in the file as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6452] RDMD shouldn't put the compiler in the rsp file
http://d.puremagic.com/issues/show_bug.cgi?id=6452 simendsjo simend...@gmail.com changed: What|Removed |Added CC||simend...@gmail.com --- Comment #1 from simendsjo simend...@gmail.com 2011-08-08 02:05:15 PDT --- https://github.com/D-Programming-Language/tools/pull/3 https://github.com/D-Programming-Language/tools/pull/8 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6453] New: Allow multiple invariant per struct/class
http://d.puremagic.com/issues/show_bug.cgi?id=6453
Summary: Allow multiple invariant per struct/class
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simend...@gmail.com
--- Comment #0 from simendsjo simend...@gmail.com 2011-08-08 03:19:03 PDT ---
I would like to use a template mixin to add some fields to a struct, but I'd
also like the template to add additional invariant checks without having to
remember to add this for all struct/classes that mixes in this code.
class C {
int a;
}
mixin template EmbedC() {
C _c;
// oops.. more than one invariant
invariant() {
assert(_c);
}
void close() {
_c = null;
}
}
struct S {
int i = 10;
invariant() {
assert(i = 10);
}
mixin EmbedC!();
}
void main() {
S s;
s.close();
s._c.a = 10; // access violation, but I want assertion from invariant
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6454] New: @property doesn't need return type
http://d.puremagic.com/issues/show_bug.cgi?id=6454
Summary: @property doesn't need return type
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simend...@gmail.com
--- Comment #0 from simendsjo simend...@gmail.com 2011-08-08 03:23:22 PDT ---
For @property, the return type is inferred even without the auto return type:
struct S {
@property p() { // missing bool/auto
return true;
}
}
void main() {
S s;
static assert(is(typeof(s.p) == bool)); // ok
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6454] @property doesn't need return type
http://d.puremagic.com/issues/show_bug.cgi?id=6454
--- Comment #1 from simendsjo simend...@gmail.com 2011-08-08 03:25:06 PDT ---
This also breaks creation of import files. Notice the double @property:
// D import file generated from 't.d'
struct S
{
@property @property p()
{
return true;
}
}
void main();
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6455] New: std.string.format doesn't understand positional arguments
http://d.puremagic.com/issues/show_bug.cgi?id=6455
Summary: std.string.format doesn't understand positional
arguments
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Optlink
AssignedTo: nob...@puremagic.com
ReportedBy: simend...@gmail.com
--- Comment #0 from simendsjo simend...@gmail.com 2011-08-08 05:15:31 PDT ---
.. At least in 2.054
import std.string;
void main() {
format(%1$s, a);
}
std.format.FormatError: std.format string
Using formattedWrite works:
import std.format, std.range;
void main() {
auto app = appender!string();
formattedWrite(app, %1$s, a);
assert(app.data == a);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4088] opEquals not called on interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=4088 --- Comment #9 from Steven Schveighoffer schvei...@yahoo.com 2011-08-08 05:47:06 PDT --- (In reply to comment #8) Issues that need to be resolved: 1. what should happen if this is called with a COM object? Compiler error. 2. how does an opEquals defined in an interface interact with the object.opEquals? If the notion of COM interfaces is specialized, then standard interfaces do not need to define opEquals, it's assumed that any standard interface (not C++ or COM) derives from Object, and implicit dynamic casting to Object to do opEquals should work. 3. a forced cast, unlike an implicit cast, is a blunt instrument that can do a lot more than simply cast an interface to its base class. If the arguments are other types, what are the conseqences of this forced cast? An implicit cast to Object would be the best remedy. However, the issue of dynamic casting and blunt casting being conflated would be a good issue to solve too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6456] New: toString fails with alias this when more than one field present
http://d.puremagic.com/issues/show_bug.cgi?id=6456
Summary: toString fails with alias this when more than one
field present
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-08-08
11:22:46 PDT ---
import std.stdio;
import std.conv;
struct Foo
{
string toString() { return to!string(x); }
alias x this;
int x;
int y; // comment this out and the bug is gone
}
void main()
{
auto foo = Foo();
writeln(foo);
}
If you comment out int y; the bug is gone, otherwise you get back this little
thingy:
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(100): Error: template
std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) isSomeString!(T)
isInputRange!(Unqual!(S)) isSomeChar!(ElementType!(S))) does not match any
function template declaration
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(100): Error: template
std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) isSomeString!(T)
isInputRange!(Unqual!(S)) isSomeChar!(ElementType!(S))) cannot deduce
template function from argument types !(int)(Foo)
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(100): Error: template
instance errors instantiating template
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(1683): Error: template
instance std.conv.to!(int).to!(Foo) error instantiating
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(328):instantiated
from here: getNthInt!(Foo)
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(678):instantiated
from here: formattedWrite!(LockingTextWriter,immutable(char),Foo)
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(1511):instantiated
from here: write!(Foo,char)
test.d(18):instantiated from here: writeln!(Foo)
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(328): Error: template
instance std.format.getNthInt!(Foo) error instantiating
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(678):instantiated
from here: formattedWrite!(LockingTextWriter,immutable(char),Foo)
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(1511):instantiated
from here: write!(Foo,char)
test.d(18):instantiated from here: writeln!(Foo)
Failed: dmd -d -debug -w -wi -unittest -v -o- test.d -I. test.d.deps
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6457] New: [CTFE] .idup or casting of char[] does not really create a string literal recognizable in 'mixin', which causes a line-less error
http://d.puremagic.com/issues/show_bug.cgi?id=6457
Summary: [CTFE] .idup or casting of char[] does not really
create a string literal recognizable in 'mixin', which
causes a line-less error
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Keywords: diagnostic, rejects-valid
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
Blocks: 5373
--- Comment #0 from kenn...@gmail.com 2011-08-08 14:11:52 PDT ---
Test case:
-
string bug6457() {
auto d = new char[6];
d[] = int a;;
return d.idup; // -- won't make a real string
// return cast(string)d; // -- neither does this
}
mixin(bug6457());
-
Error: argument to mixin must be a string, not (['i','n','t',' ','a',';'])
-
This affects all codes that uses std.array.appender. 'mixin' should be able to
accept a string casted/idup-ed from a 'char[]', or the interpreter should be
able to convert a 'char[]' expression to a StringExp in a 'cast(string)', and
no matter which solution is taken, the error of 'mixin' should have the line
number.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #29 from bearophile_h...@eml.cc 2011-08-08 14:48:37 PDT --- (In reply to comment #26) If we grow tuple support by adding piecemeal special cases for this and that, without thinking about them more globally, we are liable to build ourselves into a box we can't get out of. OK. Do you have hints on what kind of things we have to work on to solve this problem? We should step back and figure out what we want to do with tuples in the much more general case. Here I have done my best in stepping back: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=141640 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6457] [CTFE] .idup or casting of char[] does not really create a string literal recognizable in 'mixin', which causes a line-less error
http://d.puremagic.com/issues/show_bug.cgi?id=6457 Trass3r mrmoc...@gmx.de changed: What|Removed |Added CC||mrmoc...@gmx.de --- Comment #1 from Trass3r mrmoc...@gmx.de 2011-08-08 16:24:43 PDT --- Isn't this even a regression? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6014] rt_finalize Segmentation fault , dmd 2.053 on linux freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014 --- Comment #12 from changlon chang...@gmail.com 2011-08-08 19:46:06 PDT --- I think the bug is not because class cast . in the code i have Token and ASTNode, The Token is struct and ASTNode is class. if I apply them both on heap then it working fine, if I only apply ASTNode on heap the problem is still there , If I apply only Token on heap the test is work fine . I storage the pointer of Token struct on a global pointer, and print it before exit main function, find it is diffent , that mean the Pool.data has been moved , and after exit main I got a Segmentation . I simply do nothing but just change the struct Token to class Token, they still apply on pool but not heap, The problem is not exists anymore. So, I guess this is not a cast(class) issue, It is a struct issue, and related with druntime GC . the Segmentation is very rare, If i change a lite things on example.jade, the Segmentation will not exists . If i apply stuct Token on heap the performance will be very bad, It will cause 100 times than not apply on heap . After several months of debug and test, I finally resolved this problem . Thanks a lot for Steven Schveighoffer help . my problem is not exists by switch stuck Token to class Token, But I believe there is also a hidden an druntime GC bug, So I will not close this bug . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6014] rt_finalize Segmentation fault , dmd 2.053 on linux freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014 --- Comment #13 from changlon chang...@gmail.com 2011-08-08 19:57:26 PDT --- The struct implement with issue test case : http://gool.googlecode.com/files/jade_dtor_bug.tar.bz2 the class implement without issue test case : http://gool.googlecode.com/files/jade_dtor_bug_fixed.tar.bz2 I realy can't reduce the test case, because it is a runtime issue . jade is a web view template compiler, like http://www.smarty.net/ for php . jade will convert jade template language to d source for web deveplop purpose. the hark part is if i change any jade view template source ( example.jade) the isuse will not exists, so I really do not know how to reduce this test case . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6457] [CTFE] .idup or casting of char[] does not really create a string literal recognizable in 'mixin', which causes a line-less error
http://d.puremagic.com/issues/show_bug.cgi?id=6457 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2011-08-08 21:29:39 PDT --- This doesn't work either, and it doesn't involve CTFE: const char[] s = ['i','n','t',' ','a',';']; mixin(s); It's one of the few cases where arrays literals of chars aren't being accepted as string literals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6458] New: Multibyte char literals shouldn't implicitly convert to char
http://d.puremagic.com/issues/show_bug.cgi?id=6458
Summary: Multibyte char literals shouldn't implicitly convert
to char
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2011-08-08 21:43:38 PDT ---
The code below should either be rejected, or work correctly.
The particularly problematic case is: s[0..2] = '�', which looks perfectly
reasonable, but creates garbage.
I'm a bit confused about non-ASCII char literals, since although they are typed
as 'char', they can't be stored in a char... This just seems wrong.
int bug6458()
{
char [] s = abcdef.dup;
s[0] = '�';
assert(s == �cdef);
return 34;
}
void main()
{
bug6458();
}
Surely this has been reported before, but I can't find it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6458] Multibyte char literals shouldn't implicitly convert to char
http://d.puremagic.com/issues/show_bug.cgi?id=6458 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-08-08 21:53:05 PDT --- Personally, I think that all character literals should be typed as dchar, since it's generally a _bad_ idea to operate on individual chars or wchars. Normally, the only places that chars or wchars should be used is in ranges of chars or wchars (which would normally be arrays). But making character literals dchar be default might break too much code at this point. Though, since it should be possible to use range propagation to verify whether a particular code point will fit in a particular code unit, the breakage might be minimal. Regardless, I actually never would have expected s[0 .. 2] = '�' to work, since you're assigning a character to multiple characters as far as types go, though I can see why you might think that it would work or why it arguably _should_ work. Obviously though, if the compiler is allowing you to assign a code point to multiple code units like that, it should only compile if it can verify that the code unit will fit exactly in those code units, and if it does compile, it should work correctly rather than generate garbage. So, there are several issues at work here it seems. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6458] Multibyte char literals shouldn't implicitly convert to char
http://d.puremagic.com/issues/show_bug.cgi?id=6458 --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2011-08-08 22:33:20 PDT --- Ah, yes. I forgot that you could assign a single value to every element in an array like that. That being the case, it should just fail to compile given that the code point is not going to fit in each of the elements of the array. But regardless, something odd is definitely going on here given that '�'.sizeof == 2. It's probably an edge case which wasn't caught, since the only types which take up multiple elements like that are char and wchar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
