[Issue 600] error occurs when using template's tuple argument with typetuple having values
http://d.puremagic.com/issues/show_bug.cgi?id=600 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #1 from Don clugd...@yahoo.com.au 2009-10-29 01:26:59 PDT --- static assert(is(Test!(int,3,2,ubyte) == ubyte));//failed -- This one was fixed in DMD1.010 or earlier. By DMD1.020, the other two cases display a correct error message: test.d(21): alias test.Test!(4).Test cannot alias an expression 4 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3448] New: __traits(compiles) returns true for a non-compilable template instantiation
http://d.puremagic.com/issues/show_bug.cgi?id=3448
Summary: __traits(compiles) returns true for a non-compilable
template instantiation
Product: D
Version: 2.035
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha samu...@voliacable.com 2009-10-29 04:48:13
PDT ---
template Bar()
{
void Bar()
{
error;
}
}
template Foo()
{
enum Foo = __traits(compiles, Bar!());
}
static assert(!Foo!());
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3449] New: const and invariant struct members do not behave according to spec
http://d.puremagic.com/issues/show_bug.cgi?id=3449
Summary: const and invariant struct members do not behave
according to spec
Product: D
Version: 2.035
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@kyllingen.net
--- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2009-10-29
04:52:34 PDT ---
When struct members are declared const or invariant, they seem to become
manifest constants. Example:
struct Foo { const int bar = 123; }
writeln(Foo.sizeof); // Prints 1, not 4
Foo foo;
auto p = foo.bar; // Error: constant 123 is not an lvalue
The same happens if const is replaced with immutable. According to the spec it
should be possible to take the address of const/immutable variables, and in the
case of const it is even considered well-defined behaviour to change their
value after casting them to non-const. I see no reason why this shouldn't apply
to structs as well.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3447] std.file uses unconventional file permissions
http://d.puremagic.com/issues/show_bug.cgi?id=3447 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2009-10-29 06:04:42 PDT --- Good catch, thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3447] std.file uses unconventional file permissions
http://d.puremagic.com/issues/show_bug.cgi?id=3447 --- Comment #2 from Lars T. Kyllingstad bugzi...@kyllingen.net 2009-10-29 06:21:23 PDT --- I just grepped through all of Phobos for 0660, and I see that the std.mmfile module also uses these permissions. I'm not sure whether this should be changed, though, because I haven't really used memory-mapped files and don't know how they are used. Just thought I should mention it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3102] Incorrectly matching type as shared (two cases with is expressions)
http://d.puremagic.com/issues/show_bug.cgi?id=3102 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-10-29 06:47:50 PDT --- Related SVN revision: http://www.dsource.org/projects/dmd/changeset/223 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3349] typeid(shared(T)) generates wrong value
http://d.puremagic.com/issues/show_bug.cgi?id=3349 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #1 from Leandro Lucarella llu...@gmail.com 2009-10-29 06:45:51 PDT --- Related svn revision: 224 http://www.dsource.org/projects/dmd/changeset/224 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3451] Initializers don't work for tuple variables
http://d.puremagic.com/issues/show_bug.cgi?id=3451 Don clugd...@yahoo.com.au changed: What|Removed |Added Version|2.035 |1.030 --- Comment #1 from Don clugd...@yahoo.com.au 2009-10-29 08:42:27 PDT --- Applies to D1 as well. In 1.020 and earlier, the assignment was rejected. The current behaviour dates from 1.028 or earlier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3279] Type tuple comparison fails
http://d.puremagic.com/issues/show_bug.cgi?id=3279 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||diagnostic CC||clugd...@yahoo.com.au Severity|blocker |major --- Comment #1 from Don clugd...@yahoo.com.au 2009-10-29 08:53:55 PDT --- This is a diagnostic bug. The error message is highly misleading. Even this won't compile: static assert (TypeTuple!(long, int) == TypeTuple!(long, int)); And it *shouldn't* compile, since they are types, not expressions, so they can't be compared with ==. The code should be rewritten as: static assert (is(snoC!(int, TypeList!(long)).toTuple == TypeTuple!(long, int))); which compiles. Downgrading from blocker to major. While investigating this I found bug 3451. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3367] Regression: struct initialization no longer supports ctor overloads
http://d.puremagic.com/issues/show_bug.cgi?id=3367
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Don clugd...@yahoo.com.au 2009-10-29 12:58:44 PDT ---
PATCH: declaration.c, line 1094.
{
/* Look for opCall
* See bugzilla 2702 for more discussion
*/
Type *ti = ei-exp-type-toBasetype();
--- ADD THIS CODE:
// Look for ctor
if (sd-ctor
/* Initializing with the same type is done differently
*/
!(ti-ty == Tstruct t-toDsymbol(sc) == ti-toDsymbol(sc)))
{
// Rewrite as e1.call(arguments)
Expression * eCall = new DotIdExp(loc, e1, Id::ctor);
ei-exp = new CallExp(loc, eCall, ei-exp);
}
else
---
// Don't cast away invariant or mutability in initializer
if (search_function(sd, Id::call)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 971] No profiling output is generated if the application terminates with exit
http://d.puremagic.com/issues/show_bug.cgi?id=971 Justin Spahr-Summers justin.spahrsumm...@gmail.com changed: What|Removed |Added CC||justin.spahrsumm...@gmail.c ||om Version|1.005 |2.035 OS/Version|Linux |Windows --- Comment #8 from Justin Spahr-Summers justin.spahrsumm...@gmail.com 2009-10-29 15:12:09 CDT --- I don't know if this issue ever got resolved, but now it's cropping up with a void main too, even through a clean return. int main does not share the problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3452] New: Can't alias member functions such that the object name is implicitly stored in the alias
http://d.puremagic.com/issues/show_bug.cgi?id=3452
Summary: Can't alias member functions such that the object name
is implicitly stored in the alias
Product: D
Version: 2.035
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2009-10-29 14:00:43 PDT ---
struct Foo {
void bar() {}
void baz() {}
}
void doStuff(Foo foo) {
alias foo.bar fun;
fun(); // Error: need 'this' to access member bar
}
I can't think of any reason why this shouldn't work. foo.bar is a compile-time
symbol for the member function Foo.bar() on the instance foo. Once I alias
foo.bar to fun, calling fun() should be equivalent to calling foo.bar().
Even if there's some language legalese reason why this shouldn't work according
to the spec, it's still a reasonable enhancement request.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 195] DDoc generates bad output when example contains protected attribute
http://d.puremagic.com/issues/show_bug.cgi?id=195 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-10-29 14:36:56 PDT --- Related SVN revision: http://www.dsource.org/projects/dmd/changeset/227 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1117] ddoc generates corrupted docs if code examples contain attributes with colons
http://d.puremagic.com/issues/show_bug.cgi?id=1117 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #3 from Leandro Lucarella llu...@gmail.com 2009-10-29 14:37:02 PDT --- Related SVN revision: http://www.dsource.org/projects/dmd/changeset/227 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3269] pure functions silently become nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=3269 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-10-29 14:38:17 PDT --- Related SVN revision: http://www.dsource.org/projects/dmd/changeset/226 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2694] alias pure nothrow XXX; is not pure nothrow!
http://d.puremagic.com/issues/show_bug.cgi?id=2694 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-10-29 14:39:03 PDT --- Related SVN revision: http://www.dsource.org/projects/dmd/changeset/225 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3453] New: Linking order affects proper execution
http://d.puremagic.com/issues/show_bug.cgi?id=3453 Summary: Linking order affects proper execution Product: D Version: 2.035 Platform: x86_64 OS/Version: Mac OS X Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: in-c...@gmx.net --- Comment #0 from Pablo Ripolles in-c...@gmx.net 2009-10-29 16:08:57 PDT --- Created an attachment (id=484) sources, makefile and terminal window image capture * Overview: There are two source files, the main one (dependent) and the utility one (dependency). The separated compilation is successfully accomplished. The linking stage is also successfully accomplished but: 1) If we proceed with this command: $ dmd -g utility.d main.d -ofhello Then on execution it fails. 2) If we proceed with this command: $ dmd -g main.d utility.d -ofhello Then on execution it succeeds. * Steps to Reproduce: The attachment has the source files and a makefile with the second option disabled. There is also a terminal window image capture with the CLI process. Unzip the attachment. $ make $ ./hello * Actual Results: Bus error * Expected Results: hello, world * Build Date Platform: Build 2009-10-30 on Mac OS 10.5.8 * Additional Builds and Platforms: Does not occur on Build 2009-10-30 on GNU/Linux Debian 5.0.3 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3454] New: Inconsistent flag setting in GC.realloc()
http://d.puremagic.com/issues/show_bug.cgi?id=3454
Summary: Inconsistent flag setting in GC.realloc()
Product: D
Version: 2.035
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2009-10-29 17:26:42 PDT ---
GC.realloc() doesn't set the flags on either the old or new memory block for a
whole bunch of code paths. I was tipped off to this by reading the code while
trying to add precise heap scanning. Here's a test program that demonstrates
this.
import std.stdio, core.memory;
void main() {
doTest(1);
writeln();
doTest(1024 * 1024);
}
void doTest(size_t multiplier) {
auto foo = GC.malloc(8 * multiplier);
auto bar = GC.realloc(foo, 2 * multiplier, GC.BlkAttr.NO_SCAN);
writeln(Old block attributes: , GC.getAttr(foo));
writeln(New block attributes: , GC.getAttr(bar));
writeln(Old Ptr: , foo, New Ptr: , bar);
}
Output:
Old block attributes: 2
New block attributes: 2
Old Ptr: 961E40 New Ptr: 961E30
Old block attributes: 0
New block attributes: 0
Old Ptr: 10C New Ptr: 10C
This is caused by the GC returning early from the B_PAGE path, or if the new
block is almost the same size as the old block. If I get precise heap scanning
to work, I'll include a fix for this in the patch.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
