[Issue 937] C-style variadic functions broken

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=937


Dan G.  changed:

   What|Removed |Added

 CC||ven...@gmail.com


--- Comment #3 from Dan G.  2010-08-26 17:26:47 PDT ---
While working on GDC, it was found this bug still exists in 1.063.

The problem appears to be an if statement in func.c around line 811.

"parameters" is not initialized until further down in the function.  By
substituting "f->parameters" the problem is resolved.

---
// Original if statement
if (f->linkage == LINKd || (parameters && parameters->dim))

// Modified if statement
if (f->linkage == LINKd || (f->parameters && Parameter::dim(f->parameters)))



GDC ticket.
http://bitbucket.org/goshawk/gdc/issue/57/c-style-variadic-functions-broken

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4571] Non-null class references/pointers

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #2 from bearophile_h...@eml.cc 2010-08-26 17:27:34 PDT ---
An example implementation of TypeState for Java:
http://www.warski.org/blog/?cat=9
http://www.warski.org/typestate.html

The original paper about typestates, Typestate: A Programming Language Concept
for Enhancing Software Reliability", by Robert E. Strom and Shaula Yemini,
1986:
http://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestate.pdf

A version for dotnet, Typestates for Objects", by R. DeLine and M. F�hnrich:
http://www.cs.cmu.edu/~aldrich/courses/819/slides/typestates.ppt
http://research.microsoft.com/apps/pubs/default.aspx?id=67458
The software:
http://research.microsoft.com/en-us/projects/fugue/
(But it says Fugue is no longer supported as a tool. However, check out our
related project called CodeContracts.")

More on the topic:
http://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4475] Improving the compiler 'in' associative array can return just a bool

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4475



--- Comment #1 from bearophile_h...@eml.cc 2010-08-26 16:59:06 PDT ---
See also bug 4625

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4625] "in" operator for AAs in SafeD code

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4625



--- Comment #1 from bearophile_h...@eml.cc 2010-08-26 16:58:40 PDT ---
See also bug 4475

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4571] Non-null class references/pointers

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #1 from bearophile_h...@eml.cc 2010-08-26 16:41:58 PDT ---
This is just half of a solution. Beside introducing nonnull
pointers/references, and a handy syntax to denote them, to have a null-safe
language you also need to require explicit tests every time a nullable
pointers/references is about to be dereferenced, and then after this test in
the else branch the reference type "becomes" a non-nullable one.

This is an application of the idea of "TypeState", used by the Mozilla Rust
language. The type doesn't actually change, it's just its state that change.

More on the concept of TypeState (at the moment it is not present in
Wikipedia):
http://www.google.com/search?q=typestate

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #5 from Jonathan M Davis  2010-08-26 
15:47:47 PDT ---
The error message definitely needs to be improved. However, if you're arguing
for consistency, you could easily argue that the current way is not consistent
because it's not consistent with variable declarations. If I declare

const T foo;

then foo is going to be a const T. However, if I declare

const T foo() {}

then now T is not const. Rather the object that foo is a member of is const.
So, the current situation is _not_ completely consistent. It chooses to be
consistent with one feature and not another because it can't be consistent with
both. However, anyone coming from a C++ background will expect that function
declaration to return a const T and that you would have to put the const to the
right of the function name to make it const. This topic has come up a number of
times, and there are quite a few folks who think that the current situation is
flawed. There's certainly no question that it's confusing. Personally, I'd
argue that function modifiers should just go on the right of the function,
except that that would be confusing with regards to modifiers like private or
abstract which other languages put to the left of the function.

So, I'd strongly argue that it will cause fewer problems if you had to put
immutable and const to the right of the function name to make the function
immutable or const. Yes, it's inconsistent with other function modifiers, but
it's more consistent with variable declarations and other languages., and it
will causes less confusion. The other solution would be to always require
parens for const and immutable types regardless of whether they're for return
types or variable declarations, but I can't imagine that that would go over
very well.

In any case, at minimum, the error message needs to be improved.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734


Stephan Dilly  changed:

   What|Removed |Added

   Severity|normal  |enhancement


--- Comment #4 from Stephan Dilly  2010-08-26 15:16:58 PDT 
---
(In reply to comment #3)
> (In reply to comment #2)
> > You are absolutely right. I forgot about the ability to make functions
> > themselves const/immutable. It would really help if that right-side rule 
> > was in
> > place, because all this will do right now is cause confusion (unless we get 
> > a
> > nicer error message, in which case we can keep the flexibility I think..).
> > 
> > So maybe I should change this to an enhancement request for a better error
> > message.
> 
> it is nothing but consistent and should stay as it is.

sorry i should have read to the end. i aggree that the error message could be
improved ;)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734


Stephan Dilly  changed:

   What|Removed |Added

 CC||s...@extrawurst.org


--- Comment #3 from Stephan Dilly  2010-08-26 15:14:48 PDT 
---
(In reply to comment #2)
> You are absolutely right. I forgot about the ability to make functions
> themselves const/immutable. It would really help if that right-side rule was 
> in
> place, because all this will do right now is cause confusion (unless we get a
> nicer error message, in which case we can keep the flexibility I think..).
> 
> So maybe I should change this to an enhancement request for a better error
> message.

I disagree, just like any other storage class the current annotating enables
the user to group blocks of methods with equivalent storage classes like this:

class Foo{
static{
void foo();
}

const{
const(ConstReturnVal) bar();
}
}

it is nothing but consistent and should stay as it is.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734



--- Comment #2 from Andrej Mitrovic  2010-08-26 
14:53:11 PDT ---
You are absolutely right. I forgot about the ability to make functions
themselves const/immutable. It would really help if that right-side rule was in
place, because all this will do right now is cause confusion (unless we get a
nicer error message, in which case we can keep the flexibility I think..).

So maybe I should change this to an enhancement request for a better error
message.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734


Jonathan M Davis  changed:

   What|Removed |Added

 CC||jmdavisp...@gmail.com


--- Comment #1 from Jonathan M Davis  2010-08-26 
14:44:23 PDT ---
Unfortunately, this is not a bug. Putting either const or immutable on a
function - be it on the left of the function signature or the right - makes
that function immutable. If you want the return type to be const or immutable,
you _must_ use parens. As I understand it, this was done to make const and
immutable work the sames as modifiers like private, public, pure, and nothrow
(which mean the same thing regardless of which side of the function that
they're on). A number of use would like const and immutable to have to be on
the right if you want to make the function const or immutable, but Walter
doesn't agree, so it doesn't work that way.

So, your function declaration is making the function immutable, _not_ the
return type. The reason why using const with your unit test works but immutable
does not is because both mutable and immutable values can be used with const
functions, but only immutable ones can be used with immutable functions.

immutable test = new Test;
test.foo();

should work just fine with the way that you declared the function. Now, I think
that the error message definitely needs some work; it should indicate that the
variable needs to be immutable rather than talking about the function arguments
(it's probably doing that because the this pointer is an invisible function
argument), but it is essentially correct.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4737] New: enum breaks linker when passed to typeid()

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4737

   Summary: enum breaks linker when passed to typeid()
   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  2010-08-26 
14:34:39 PDT ---
module test;

import std.stdio;

unittest
{
enum X { A = 3, B, C }
X x; 

write(typeid(x));
write(typeid(X));   
}

void main()
{
}

 Error 42: Symbol Undefined _D4test11__unittest1FZv1X6__initZ

Sometimes it will compile, but then the app crashes and I get an access
violation message in console.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4736] New: http://www.digitalmars.com/d/2.0/hash-map.html

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4736

   Summary: http://www.digitalmars.com/d/2.0/hash-map.html
   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  2010-08-26 
14:27:13 PDT ---
Example under "Using Classes as the KeyType" has some typos (f instead of foo),
fix to:

class Foo
{
int a, b;

hash_t toHash() { return a + b; }

bool opEquals(Object o)
{
Foo foo = cast(Foo) o;
return foo && a == foo.a && b == foo.b;
}

int opCmp(Object o)
{
Foo foo = cast(Foo) o;
if (!foo)
return -1;
if (a == foo.a)
return b - foo.b;
return a - foo.a;
}
}

Example under "Using Structs or Unions as the KeyType" has a typo (s instead of
str) fix to:

import std.string;

struct MyString
{
string str;

const hash_t toHash()
{   
hash_t hash;
foreach (char c; str)
hash = (hash * 9) + c;
return hash;
}

const bool opEquals(ref const MyString s)
{
return std.string.cmp(this.str, s.str) == 0;
}

const int opCmp(ref const MyString s)
{
return std.string.cmp(this.str, s.str);
}
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3976] segfault on anonymous struct/union

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3976



--- Comment #4 from Ellery Newcomer  2010-08-26 
14:25:04 PDT ---
(In reply to comment #3) 
> 
> There is no kmd file. Also this code seems to use Tango (dunno which 
> version!).
> So it's not a usable test case. But I'm pretty sure this is the same as 4543.
> Reopen if you think it is not the same, and have some kind of usable test 
> case.
> 
> *** This issue has been marked as a duplicate of issue 4543 ***

I have little to no recollection of filing this isssue (and I agree it's pretty
bad), but I don't think issue 4543 sounds like what this one was. I'll try
digging things up this weekend. Sorry to waste your time, Don.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4080] Patch for building dynamic libraries on Mac OS X

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4080



--- Comment #5 from Walter Bright  2010-08-26 
14:21:48 PDT ---
http://www.dsource.org/projects/dmd/changeset/372

I changed the location of the new files to be more consistent with druntime's
existing conventions:

Adding src\core\sys\osx\mach\dyld.d
Adding src\core\sys\osx\mach\getsect.d
Adding src\core\sys\osx\mach\loader.d
Adding src\rt\dylib_fixes.c
Adding src\rt\image.d

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4735] New: class that implements interface can override a static method

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4735

   Summary: class that implements interface can override a static
method
   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  2010-08-26 
14:18:14 PDT ---
According to the docs:

"Classes that inherit from an interface may not override final or static
interface member functions."

module test;

void main()
{
}

interface D 
{
void bar();
static void foo() { }
final void abc() { }
}

class C : D {
void bar() { } // ok
void foo() { } // passes, but should not
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4734] New: immutable return type specifier without parantheses confuses the compiler

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4734

   Summary: immutable return type specifier without parantheses
confuses the compiler
   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  2010-08-26 
14:15:31 PDT ---
import std.stdio;

class Test
{
immutable char foo()
{
return 'z';
}
}

unittest
{
auto test = new Test;
test.foo();
}

void main()
{
}

error:
test2.d(16): Error: function test2.Test.foo () immutable is not callable using
argument types ()

Note that using const instead of immutable works.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4733] New: Possible bugs caused by dynamic arrays in boolean evaluation context

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4733

   Summary: Possible bugs caused by dynamic arrays in boolean
evaluation context
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-08-26 14:12:04 PDT ---
In Python it is a normal idiom to test for collection emptiness just putting
their name in a boolean evaluation context (this is an idom valid for all
Python collections):

arr = [1]
assert arr


But in D similar code causes troubles, this differt code shows an example:


void main() {
int[] arr = [1];
int* orig_ptr = arr.ptr;
arr.length = 0;
assert(!!arr); // this doesn't assert
assert(arr.ptr == orig_ptr); // this doesn't assert
}


!!arr is true because while arr.length is zero, arr.ptr is not null.

To avoid possible bugs (for example for programmers coming from Python
language) I suggest to turn "if(arr)" into a syntax error, forcing to use
"if(arr.length)" or "if(arr.ptr)" or similar things, and you avoid possible
bugs. In the uncommon cases where you want to test both fields to be empty, you
may use "if(arr.length || arr.ptr)" or "if(arr.length != arr.init)" or similar
things.

The semantics of "if(aa)" and "if(static_arr)", the first tests if the
reference is null, the second if all items are empty.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4602] Header generation turns 'typeof(x)(...)' into C-style cast

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4602


Don  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #1 from Don  2010-08-26 13:25:35 PDT ---
Fixed http://www.dsource.org/projects/dmd/changeset/629
as part of bug 4713.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4721] compilation slow when compiling unittests on dcollections

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4721


bearophile_h...@eml.cc changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||bearophile_h...@eml.cc
 Resolution|FIXED   |


--- Comment #10 from bearophile_h...@eml.cc 2010-08-26 13:19:39 PDT ---
Reopened, because you have added here a second different performance bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4732] New: __traits(identifier) performs constant folding on symbols

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4732

   Summary: __traits(identifier) performs constant folding on
symbols
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: patch, rejects-valid
  Severity: minor
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com


--- Comment #0 from Shin Fujishiro  2010-08-26 12:13:50 PDT 
---
Created an attachment (id=741)
Patch against dmd r621

__traits(identifier) tries to fold its argument to a constant. And symbols of
manifest constants cannot be obtained via the traits:
 test.d
enum symbol = 42;
pragma(msg, __traits(identifier, symbol), " = ", symbol);

% dmd -c -o- test
test.d(2): Error: argument 42 has no identifier
false = 42


For the 'identifier' traits, folding an argument to a constant does not make
sense. The proposed patch fixes the problem by disabling constfold on arguments
as done in the 'isSame' traits.

With the patch, the result gets corrected:

% dmd-patched -c -o- test
symbol = 42

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4721] compilation slow when compiling unittests on dcollections

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4721



--- Comment #9 from Steven Schveighoffer  2010-08-26 
11:42:02 PDT ---
(In reply to comment #8)
> Flat profile:
> 
> Each sample counts as 0.01 seconds.
>   %   cumulative   self  self total
>  time   seconds   secondscalls  ms/call  ms/call  name
>  75.79  6.51 6.51 8103 0.80 0.80 
> TemplateDeclaration::toJsonBuffer(OutBuffer*)
>   3.14  6.78 0.27  1668093 0.00 0.00 
> StructDeclaration::semantic(Scope*)

That table of functions is invalid -- I somehow compiled dmd wrong when running
that profile.  I think I used a unit test build.  However, that was only the
profiled version, the non-profiled version still takes 20 seconds to compile
dcollections.

In any case, here is the correctly profiled version's heavy hitters:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total
 time   seconds   secondscalls  ms/call  ms/call  name
 80.31 11.9911.9919000 0.63 0.63  searchfixlist
  0.67 12.09 0.10   203173 0.00 0.00  StringTable::search(char
const*, unsigned int)
  0.60 12.18 0.09   369389 0.00 0.00  Lexer::scan(Token*)
  0.54 12.26 0.08   953613 0.00 0.00  ScopeDsymbol::search(Loc,
Identifier*, int)
  0.47 12.33 0.07  1449798 0.00 0.00  calccodsize

Note, this profile is different from the first in that I was compiling the
*entire* dcollections library, not just HashMap (which is now bearable due to
the improved performance!).  This is why the # calls is much higher on this one
compared to the original.

So the last significant performance problem here is searchfixlist. Looking
back, it was 2% of the runtime before, now it's jumped to 80%.

Looking at the function in backend/cod3.c, it appears to be another linear
search through a linked list.  I understand much less about this function than
the other, so I'm not sure how/if it should be solved.  Perhaps another hash
map?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4713] PATCH for interface generation: cleanup, bugfixes and prettyprinting

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4713


Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #1 from Walter Bright  2010-08-26 
11:22:18 PDT ---
Did bugfixes part of the patches.

http://www.dsource.org/projects/dmd/changeset/629

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4681] Appender access violation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4681



--- Comment #15 from nfx...@gmail.com 2010-08-26 10:12:08 PDT ---
(In reply to comment #14)
> I'm not assuming anything about the memory layout.  GC.qalloc gives me a block
> of data, and I'm using the data.  Its interface is well defined without any
> hidden assumptions.

That mess is mostly gone, but there's still that commented stuff. Will it be
readded later?

> Besides, you are calling the same runtime functions, just using a different
> interface.  I don't see how one is more "dirty" than the other, we are both
> using well-documented runtime functions.

It doesn't zero the additional memory returned by GC.extend().
If precise GC is introduced, that won't be handled correctly either.

> Your code calls the lifetime runtime functions, which call the GC runtime
> functions.  My code just calls the GC functions, skipping the lifetime
> functions.  Like your code, mine only calls runtime functions on exhaustion.

The only real overhead is due to array initialization.
If that is really so important, the runtime should provide a clean interface to
allocate arrays uninitialized (or zeroed if not NO_SCAN). Basically a
_d_arraysetlengthT without the initialization code. That would be useful for
other code too; most time you create an array, you overwrite all its contents
anyway.

Keep in mind that optimizing the runtime code might be more worthwhile than
optimizing Appender.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4731] New: cannot call protected base class method by using base class name

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4731

   Summary: cannot call protected base class method by using base
class name
   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  2010-08-26 09:41:13 PDT 
---
the way how one has to invoke protected base class methods in D seems to be
inconsistent. why do i have to use the super keyword ? using the base class
name works in case of being public, why is protected any different ?


module Foo;

class Base
{
protected void foo() {}
}

module main;

import Foo;

class Super : Base
{
override protected void foo() {super.foo();} // works
//override void foo() {Base.foo();} // does not work:
//Error: class Foo.Base member foo is not accessible
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4139] Forward reference error in front() of iterable struct

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4139


bearophile_h...@eml.cc changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #1 from bearophile_h...@eml.cc 2010-08-26 07:58:48 PDT ---
This bug is missing in dmd 2.048, so I close it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4717] std.bitmanip.BitArray changes

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4717



--- Comment #8 from bearophile_h...@eml.cc 2010-08-26 07:56:20 PDT ---
See also bug 4124 and bug 4123

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4729] std.algorithm: strange iota behaviour

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4729



--- Comment #2 from Max Klyga  2010-08-26 07:50:27 PDT ---
This bug was introduced in 2.048, as is 2.047 iota stops but fails shortly
after:
src/phobos/std/algorithm.d(279): Enforcement failed

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3976] segfault on anonymous struct/union

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3976


Don  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


--- Comment #3 from Don  2010-08-26 07:40:22 PDT ---
(In reply to comment #1)
> Okay, for some reason my test case doesn't seem to be working. I'm sure it was
> earlier, but I deleted the file, etc. 
> 
> Here it is if anyone cares:
> 
> http://personal.utulsa.edu/~ellery-newcomer/dxl.zip
> 
> unzip it and run dmd @kmd.

There is no kmd file. Also this code seems to use Tango (dunno which version!).
So it's not a usable test case. But I'm pretty sure this is the same as 4543.
Reopen if you think it is not the same, and have some kind of usable test case.

*** This issue has been marked as a duplicate of issue 4543 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4543] Regression(1.054, 2.038) typedef circular definition and segfault

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4543


Don  changed:

   What|Removed |Added

 CC||ellery-newco...@utulsa.edu


--- Comment #7 from Don  2010-08-26 07:40:22 PDT ---
*** Issue 3976 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 4681] Appender access violation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4681



--- Comment #14 from Steven Schveighoffer  2010-08-26 
06:30:03 PDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > Why are runtime calls dirty?  I don't use any undocumented runtime 
> > functions...
> 
> Because they do more work than necessary and rely on more implementation
> details than necessary. Also, more bugs (oh hey look, we're posting in a bug
> report). I'm most worried about the assumptions of the array memory layout.

I'm not assuming anything about the memory layout.  GC.qalloc gives me a block
of data, and I'm using the data.  Its interface is well defined without any
hidden assumptions.

Besides, you are calling the same runtime functions, just using a different
interface.  I don't see how one is more "dirty" than the other, we are both
using well-documented runtime functions.

> 
> > Because the call to the runtime cannot be inlined, and is much slower than
> > simply dereferencing a pointer.  Appender is supposed to be as fast as 
> > possible
> > at appending.
> 
> My code only calls runtime functions when the capacity is exhausted. As long 
> as
> there's enough capacity, not a single runtime function is called on appending.
> It's really similar to all the code that has been in Appender before, except
> less dirty.

Your code calls the lifetime runtime functions, which call the GC runtime
functions.  My code just calls the GC functions, skipping the lifetime
functions.  Like your code, mine only calls runtime functions on exhaustion.

BTW, the statement I was responding to asked why you can't just use runtime
functions to determine capacity, I interpreted that as you wishing to use the
runtime management of array memory for every append.  I hadn't read your code
yet.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4021] [CTFE] AA rehash

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4021



--- Comment #3 from bearophile_h...@eml.cc 2010-08-26 06:31:44 PDT ---
With dmd 2.048 the error message is a little different:

...\dmd\src\druntime\import\object.di(354): Error: _aaRehash cannot be
interpreted at compile time, because it has no available source code
test.d(3): Error: cannot evaluate aa.rehash() at compile time
test.d(6): Error: cannot evaluate foo() at compile time
test.d(6): Error: cannot evaluate foo() at compile time

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4730] New: std.c.stdlib.exit in CTFE

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4730

   Summary: std.c.stdlib.exit in CTFE
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2010-08-26 06:25:39 PDT ---
This enhancement request comes from bug 4005

Currently (dmd 2.048) the following program prints:
test.d(3): Error: exit cannot be interpreted at compile time, because it has no
available source code
test.d(6): Error: cannot evaluate foo() at compile time
test.d(6): Error: static assert  (foo() == 100) is not evaluatable at compile
time


import std.c.stdlib: exit;
int foo() {
exit(1);
return 100;
}
static assert(foo() == 100);
void main() {}


I'd like exit() to work at compile-time too, and stop the compilation
gracefully (dmd return value is the value given to exit()).

See also bug 3952

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4721] compilation slow when compiling unittests on dcollections

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4721



--- Comment #8 from Steven Schveighoffer  2010-08-26 
06:22:33 PDT ---
This helps, but only reduces it to 20 seconds (but a 66% reduction is pretty
good!).  I ran another round of profiling, and found we have a new bottleneck:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total
 time   seconds   secondscalls  ms/call  ms/call  name
 75.79  6.51 6.51 8103 0.80 0.80 
TemplateDeclaration::toJsonBuffer(OutBuffer*)
  3.14  6.78 0.27  1668093 0.00 0.00 
StructDeclaration::semantic(Scope*)
  2.10  6.96 0.181   180.00   180.00  do32bit(FL, evc*, int)
  1.98  7.13 0.1715445 0.01 0.01 
EnumDeclaration::toJsonBuffer(OutBuffer*)
  0.70  7.19 0.06   656268 0.00 0.00 
Port::isSignallingNan(long double)
  0.47  7.23 0.04   915560 0.00 0.00 
StructDeclaration::toCBuffer(OutBuffer*, HdrGenState*)
  0.47  7.27 0.04 Dsymbol::searchX(Loc,
Scope*, Identifier*)

This time, I question whether toJsonBuffer should be called at all, as I'm not
outputting any JSON data?

Walter, reopen if you think this could still use improvement.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4681] Appender access violation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4681



--- Comment #13 from nfx...@gmail.com 2010-08-26 06:20:17 PDT ---
(In reply to comment #12)
> Why are runtime calls dirty?  I don't use any undocumented runtime 
> functions...

Because they do more work than necessary and rely on more implementation
details than necessary. Also, more bugs (oh hey look, we're posting in a bug
report). I'm most worried about the assumptions of the array memory layout.

> Because the call to the runtime cannot be inlined, and is much slower than
> simply dereferencing a pointer.  Appender is supposed to be as fast as 
> possible
> at appending.

My code only calls runtime functions when the capacity is exhausted. As long as
there's enough capacity, not a single runtime function is called on appending.
It's really similar to all the code that has been in Appender before, except
less dirty.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4729] std.algorithm: strange iota behaviour

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4729


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc
Summary|std.algorithm: atrange iota |std.algorithm: strange iota
   |behaviour   |behaviour


--- Comment #1 from bearophile_h...@eml.cc 2010-08-26 06:04:08 PDT ---
It seems a iota() problem.


import std.algorithm: reduce, filter;
import std.range: iota;
void main() {
reduce!"0"(filter!((int a){ return false; })(iota(1)));
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4681] Appender access violation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4681



--- Comment #12 from Steven Schveighoffer  2010-08-26 
05:51:15 PDT ---
(In reply to comment #11)
> This is still full of dirty runtime calls and attempts to emulate half of
> lifetime.d (though the worst part is commented).

Why are runtime calls dirty?  I don't use any undocumented runtime functions...

It doesn't emulate lifetime, except for the newCapacity function (which
arguably could be a call into the runtime, but it's a simple enough function,
and doesn't really have to be consistent with the runtime), and the use of
GC.extend.  I'm notably not trying to store the length inside the memory block.

> Why doesn't it simply use the D standard way to re-allocate an array, and then
> use array.capacity to see how much can be safely appended?

Because the call to the runtime cannot be inlined, and is much slower than
simply dereferencing a pointer.  Appender is supposed to be as fast as possible
at appending.

If you want to use built-in appending, just use it.  Appender is for getting
the highest possible performance out of an array.

> 
> Something along the lines of:
> 
> private struct Data {
>T[] arr;
>size_t user_length;
> }
> 
> Data _data;
> 
> void put(T item) {
>if (_data.user_length == arr.length) {
>   size_t newcapacity = something larger than user_length;
>   reallocate(newcapacity);
>}
>_data.arr[_data.user_length++] = item;
> }
> 
> void reallocate(size_t newcapacity) {
>_data.arr.length = newcapacity;
>//include the data "overallocated" by the runtime into the array
>size_t realcap = _data.arr.capacity;
>_data.arr.length = realcap;
> }
> 
> T[] data() {
>T[] arr = _data.arr[0.._data.user_length];
>_data = _data.init;
>assumeSafeAppend(arr);
>return arr;
> }
> 
> Or did I overlook something.

This is a different way of doing it, though I'd probably replace reallocate
with a standard ~=.  I think your way would work fine.

I agree your way seems more congruent with the runtime.  I wonder if there are
any advantages to doing it that way?  I think the Appender I committed is going
to be slightly faster in the long run, because it avoids using runtime
appending at all.  However, it has some limitations in that it cannot use the
rest of a passed in memory block (i.e. the space beyond the initial array). 
But your code gave me an idea of how to achieve that.  I think this should
work:

this(T[] arr)
{
   _data = new Data;
   _data.arr = arr;
   auto cap = arr.capacity;
   if(cap > origlen)
  arr.length = cap; // use up the rest of the block
   _data.capacity = arr.length;
}

I'll add this change too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4681] Appender access violation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4681



--- Comment #11 from nfx...@gmail.com 2010-08-26 05:20:08 PDT ---
This is still full of dirty runtime calls and attempts to emulate half of
lifetime.d (though the worst part is commented).

Why doesn't it simply use the D standard way to re-allocate an array, and then
use array.capacity to see how much can be safely appended?

Something along the lines of:

private struct Data {
   T[] arr;
   size_t user_length;
}

Data _data;

void put(T item) {
   if (_data.user_length == arr.length) {
  size_t newcapacity = something larger than user_length;
  reallocate(newcapacity);
   }
   _data.arr[_data.user_length++] = item;
}

void reallocate(size_t newcapacity) {
   _data.arr.length = newcapacity;
   //include the data "overallocated" by the runtime into the array
   size_t realcap = _data.arr.capacity;
   _data.arr.length = realcap;
}

T[] data() {
   T[] arr = _data.arr[0.._data.user_length];
   _data = _data.init;
   assumeSafeAppend(arr);
   return arr;
}

Or did I overlook something.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4729] New: std.algorithm: atrange iota behaviour

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4729

   Summary: std.algorithm: atrange iota behaviour
   Product: D
   Version: D2
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Optlink
AssignedTo: nob...@puremagic.com
ReportedBy: necrom...@gmail.com


--- Comment #0 from Max Klyga  2010-08-26 05:16:40 PDT ---
import std.stdio, std.algorithm, std.range;

void main() {
filter!((int n) { write(n, ' '); return 0; })(iota(1, 10));
//writes: 1 2 3 4 5 6 7 8 9

writeln();

reduce!"0"(
filter!((int n) { write(n, ' '); return 1; })(iota(1, 10))
); //writes: 1 2 3 4 5 6 7 8 9

writeln();

reduce!"0"(
filter!((int n) { write(n, ' '); return 0; })(iota(1, 10))
); //Never stops writing numbers
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4681] Appender access violation

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4681


Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com


--- Comment #10 from Steven Schveighoffer  2010-08-26 
04:56:47 PDT ---
I checked in hopefully a fix for this.

changeset http://www.dsource.org/projects/phobos/changeset/1929

Note, I changed the interface of Appender slightly to be safer.  Instead of
taking an array reference pointer, it takes an array.  This means your original
array passed in will *not* be appended to.  To get the resulting data after
appending, use the data method.

I didn't find any cases in Phobos that were adversely affected by this change
(but I did have to change a few modules that used appender in unit tests).

I tested the new version against the original code in this bug, and Don's code
in comment 8, both no longer exhibit errors.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4726] writeln(0.0 / 0.0) prints -nan

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4726



--- Comment #2 from bearophile_h...@eml.cc 2010-08-26 00:50:46 PDT ---
OK. Thank you for your answer. I will not reopen this bug because it's a minor
thing, but I don't like it because:

>From a purely ideal point of view, a NaN isn't a number, so it can't be
positive or negative, it's "undefined", that is not negative.

In 0.0/0.0 both values are positive, so if you extend the semantics of division
between two positive real numbers, the result can't be negative.

And because no other language I know of (including D printf) seems to print a
"negative nan" in that situation:

---

In D (2.048) if you run this program:

import std.stdio;
void main() {
  printf("%f\n", 0.0 / 0.0);
}


It prints "nan".

---

This D1 program (dmd 1.026):

import std.stdio;
void main() {
  writefln("%f", 0.0 / 0.0);
}


Prints "nan".

---

In C if you run this program:

#include "stdio.h"
int main() {
  printf("%f\n", 0.0 / 0.0);
  return 0;
}

It prints "nan".

---

In Scala language, this program:

import java.io.{BufferedReader, InputStreamReader}

object Main {
  def main(args: Array[String]) {
  System.out.println(0.0 / 0.0);
  }
}

Prints "NaN".

---

In Haskell (that is a quite mathematical-oriented language), this program:

main = do
   putStr  (show (0.0 / 0.0))


Prints "NaN".

---

In F#, this program:

open System
do
System.Console.Write(0.0 / 0.0)

Prints "NaN".

---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4728] New: Crash by protected/private constructor in an other module

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4728

   Summary: Crash by protected/private constructor in an other
module
   Product: D
   Version: D2
  Platform: Other
OS/Version: Windows
Status: NEW
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rayerd@gmail.com


--- Comment #0 from Haruki Shigemori  2010-08-26 00:45:57 
PDT ---
// a.d
import b;
void main()
{
new A();
}

// b.d
class A
{
protected this(){}

}


When these source codes are compiled with dmd trunk r628, dmd outputs a correct
error message and crashes.


>dmd a b
a.d(4): Error: class b.A member this is not accessible
<-- crash!!


The cause of the crash is an access to the null pointer as shown below.


// toctype.c
...
type *TypeFunction::toCtype()
{   type *t;

if (ctype)
return ctype;

if (1)
{
param_t *paramtypes;
tym_t tyf;
type *tp;

paramtypes = NULL;
size_t nparams = Parameter::dim(parameters);
for (size_t i = 0; i < nparams; i++)
{   Parameter *arg = Parameter::getNth(parameters, i);
tp = arg->type->toCtype();
if (arg->storageClass & (STCout | STCref))
{   // C doesn't have reference types, so it's really a pointer
// to the parameter type
tp = type_allocn(TYref, tp);
}
param_append_type(¶mtypes,tp);
}
tyf = totym();
t = type_alloc(tyf);
t->Tflags |= TFprototype;
if (varargs != 1)
t->Tflags |= TFfixed;
ctype = t;
t->Tnext = next->toCtype(); //  next is null
t->Tnext->Tcount++;
t->Tparamtypes = paramtypes;
}
ctype = t;
return t;
}
...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---