[Issue 8717] New: `private` and `protected` restrict member usage in same module

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8717

   Summary: `private` and `protected` restrict member usage in
same module
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com


--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-09-24 
09:56:32 MSD ---
---
struct C // struct, class, or union
{
private: // private or protected, for package see Issue 8716
enum e = 0;
immutable static int si = 0;
static int sf() { return 0; }
immutable int i = 0;
int f() const { return 0; }
}

static assert(C.e == 0);
static assert(C.si == 0);
static assert(C.sf() == 0);
static assert(C.i == 0);

static assert(C.init.e == 0);
static assert(C.init.si == 0); // undefined identifier 'si'
static assert(C.init.sf() == 0); // struct main.C member sf is not accessible
static assert(C.init.i == 0);
static assert(C.init.f() == 0); // struct main.C member f is not accessible
---
There is no such errors if asserts are e.g. in a function.

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


[Issue 8716] `package` restricts members usage in same module if there is no package name

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8716


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-23 22:57:26 
PDT ---
I'm not sure that this is a bug, though the behavior is obviously surpising.
Technically speaking, your module isn't _in_ a package, so naturally it won't
have access to anything with package level access. For a module to be in a
package, it needs to be explicitly put in one. e.g.

module x.y;

Without that first x., it's a module without a package, because there is no
top-level package which holds modules which aren't explicitly put in a package.

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


[Issue 8716] `package` restricts members usage in same module if there is no package name

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8716



--- Comment #2 from Denis Shelomovskij verylonglogin@gmail.com 2012-09-24 
10:08:05 MSD ---
Of course, but it's common in D that there is no access restrictions in the
same module at all.

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


[Issue 8718] New: Template mixin + string mixin name collision

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8718

   Summary: Template mixin + string mixin name collision
   Product: D
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com


--- Comment #0 from monarchdo...@gmail.com 2012-09-23 23:47:48 PDT ---
From the (simplified) discussion @
http://forum.dlang.org/thread/xmoqikjmwfhqmuunc...@forum.dlang.org


mixin template T(string s)
{
   void f()
   {
   mixin(++ ~ s ~ ;); //L5
   }
}

struct S
{
   int x;
}

void main() {
   S a;
   S s;
   mixin T!(a.x);
   mixin T!(s.x); //L18
}

main.d(5): Error: undefined identifier 'x', did you mean 'struct S'?
main.d(18): Error: mixin main.main.T!(s.x) error instantiating


When trying to instantiate the template mixin T the second time with s.x, the
compiler gets confused because the name of the string parameter is also s,
making s.x illegal.

I think this is a catch 22:

- On the one hand, the code generated by the template is, AFAIK, genuinely
illegal, as s shadows the outside world's s, and the generated s.x is indeed
illegal.

- On the other hand, I think it is not conceivable to tell a client your code
failed to work, because you declared your variable with the same name as the
argument of a function: You are not allowed to call your variable s because
it's taken. WHAT?

Not sure what to make of this...

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


[Issue 6625] Distribute newer Windows API import libraries

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6625


Damian damian...@hotmail.co.uk changed:

   What|Removed |Added

 CC||damian...@hotmail.co.uk


--- Comment #1 from Damian damian...@hotmail.co.uk 2012-09-24 03:57:05 PDT ---
I absolutely agree they are WAY outdated! Why is DMD not coming with the newest
versions available?

To put it bluntly, what use is outdated libraries to any windows programmer??

The first thing one does is resort to the WindowsApi bindings project - which
should be an unnecessary step.

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


[Issue 8713] Allow passing arguments to templates in CTFE

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8713


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #1 from Don clugd...@yahoo.com.au 2012-09-24 05:04:56 PDT ---
What you are asking for is this:
(a) things wrapped in if (__ctfe) don't get fully semantically checked when the
function is compiled.
(Specifically, anything which needs a compile-time value doesn't get checked
for 'readable at compile time').

(b) CTFE functions never get compiled. When a template is encountered inside a
CTFE function, it is created during execution of the function.

Your enhancement request acts as if (a) is the problem, but it isn't. (a) is an
intentional restriction to protect us from (b) which is very, very nasty. It's
not merely implementation issues (although they are formidable). Fundamentally
it violates the independence of the compiler passes, which is crucial to the
design of D (you always finish one pass before you start the next).

Just to name one problem: accepting this request would make it impossible to
have a clean JIT-based implementation of CTFE. Because of this I think it
closes more doors than it opens.

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


[Issue 8713] Allow passing arguments to templates in CTFE

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8713



--- Comment #2 from jens.k.muel...@gmx.de 2012-09-24 05:33:43 PDT ---
(In reply to comment #1)
 What you are asking for is this:
 (a) things wrapped in if (__ctfe) don't get fully semantically checked when 
 the
 function is compiled.
 (Specifically, anything which needs a compile-time value doesn't get checked
 for 'readable at compile time').
 
 (b) CTFE functions never get compiled. When a template is encountered inside a
 CTFE function, it is created during execution of the function.
 
 Your enhancement request acts as if (a) is the problem, but it isn't. (a) is 
 an
 intentional restriction to protect us from (b) which is very, very nasty. It's
 not merely implementation issues (although they are formidable). Fundamentally
 it violates the independence of the compiler passes, which is crucial to the
 design of D (you always finish one pass before you start the next).

Why is the independence of compiler passes crucial to the design of D? What
would break if the compiler was implemented differently?

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


[Issue 7021] Structs with disabled default constructors can be constructed without calling a constructor.

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7021


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #15 from Don clugd...@yahoo.com.au 2012-09-24 06:31:57 PDT ---
(In reply to comment #13)
 (In reply to comment #12)
  For structs, as long as there is no static opCall declared, S() and S.init
  should be identical, 
 
 This is not already true for nested structs.
 
 void main() {
 int g = 10;
 struct S {
 int n;
 auto foo(){ return g; }
 }
 auto s1 = S();  // StructLiteralExp
 assert(s1.tupleof[$-1] !is null);  // hidden ptr is filled
 assert(s1.foo() == 10);// OK
 auto s2 = S.init;
 assert(s2.tupleof[$-1]  is null);  // hidden ptr isn't filled
 assert(s2.foo() == 10);// Access Violation!
 }

That's a bug: .init for nested structs is garbage. It's the cause of bug 6419,
for example. defaultInitLiteral() is wrong.

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


[Issue 8150] Throwing nothrow struct constructor?

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8150



--- Comment #3 from github-bugzi...@puremagic.com 2012-09-24 07:47:09 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/c519a4d9dcc8b65aaadba2f30fdecf63bec5df99
fix Issue 8150 - Throwing nothrow struct constructor?

https://github.com/D-Programming-Language/dmd/commit/36e0a9b975941aac4bf5bd6fd044e6acbf2504e9
Merge pull request #1138 from 9rnsr/fix8150

Issue 8150 - Throwing nothrow struct constructor?

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


[Issue 8708] Documentation for std.process.exec family is inaccurate

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8708


Greg Ward g...@gerg.ca changed:

   What|Removed |Added

 CC||g...@gerg.ca


--- Comment #1 from Greg Ward g...@gerg.ca 2012-09-24 08:31:37 PDT ---
Coincidentally, I discovered this doc bug at about the same time. So I
submitted a pull request:
https://github.com/D-Programming-Language/phobos/pull/812 .

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


[Issue 7021] Structs with disabled default constructors can be constructed without calling a constructor.

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7021



--- Comment #16 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-24 08:32:45 
PDT ---
 That's a bug: .init for nested structs is garbage. It's the cause of bug 6419,
for example. defaultInitLiteral() is wrong.

Then I _definitely_ think that S() and S.init should always be the same for
structs as long as static opCall has not been declared, and

@disable this();

should disable S.init such that it's impossible to ever default-initialize S or
to use S.init or to use S() (though S() should still work if static opCall is
declared).

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


[Issue 7021] Structs with disabled default constructors can be constructed without calling a constructor.

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7021



--- Comment #17 from Kenji Hara k.hara...@gmail.com 2012-09-24 08:47:32 PDT 
---
(In reply to comment #15)
 That's a bug: .init for nested structs is garbage. It's the cause of bug 6419,
 for example. defaultInitLiteral() is wrong.

Hmmm? Now all cases in bug 6419 run correctly. In current, by fixing bug 7965,
TypeStruct::defaultInitLiteral always returns StructLiteralExp.

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


[Issue 7021] Structs with disabled default constructors can be constructed without calling a constructor.

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=7021



--- Comment #18 from Kenji Hara k.hara...@gmail.com 2012-09-24 09:10:23 PDT 
---
(In reply to comment #16)
 Then I _definitely_ think that S() and S.init should always be the same for
 structs as long as static opCall has not been declared

I cannot agree with your this opinion.

If S() is identical with S.init, default construction of nested struct will
cause Access Violation in anywhere. It means that s1 would be broken at the
example in comment#13. It is terrible language semantics.

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


[Issue 8719] New: spawnvp() (POSIX) throws exception in fork()ed child process

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8719

   Summary: spawnvp() (POSIX) throws exception in fork()ed child
process
   Product: D
   Version: D2
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: g...@gerg.ca


--- Comment #0 from Greg Ward g...@gerg.ca 2012-09-24 09:23:06 PDT ---
On POSIX systems, std.process.spawnvp() exposes its implementation to the
caller in an unexpected way: if the call to std.c.process.execvp() fails, it
throws an exception *in the forked child process*. Sample program:

import std.stdio;
import std.process;

int main() {
string[] command = [nosuchcommand];
int status;
writefln([pid %d]: spawning %s, getpid(), command);
try {
status = spawnvp(P_WAIT, command[0], command);
}
catch (Exception err) {
stderr.writefln([pid %d] %s failed: %s,
getpid(), command[0], err.msg);
return -1;
}
writefln([pid %d] %s exited with status %d,
 getpid(), command[0], status);
return status;
}

Running it produces this output:

[pid 8923] spawning [nosuchcommand]
[pid 8924] nosuchcommand failed: Cannot spawn nosuchcommand; No such file or
directory [errno 2]
[pid 8923] nosuchcommand exited with status 255

The unexpected surprise is that *both* of my post-spawnvp() writefln() calls
happen. I expected the writefln() in the catch block to be called, but not the
one outside the catch block. The explanation is obvious once you add the PID.

The workaround is fairly easy: catch Exception and turn it into return -1 (or
whatever you please). However, this is probably *not* the right thing to do on
Windows, where there is no fork() call. Basically the problem is that the POSIX
implementation of spawnvp() leaks an implementation detail: the use of fork().

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


[Issue 8150] Throwing nothrow struct constructor?

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8150


bearophile_h...@eml.cc changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #4 from bearophile_h...@eml.cc 2012-09-24 09:50:47 PDT ---
Now compiling this code:

struct Foo {
this(int) nothrow { // line 2
throw new Exception(something);
}
}
void main() {
Foo(1);
}


It gives:

temp.d(3): Error: object.Exception is thrown but not caught
temp.d(2): Warning: statement is not reachable
temp.d(2): Error: constructor temp.Foo.this 'this' is nothrow yet may throw

What's the statement not not reachable at line 2?

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


[Issue 8633] core.atomic not documented

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8633


kekeni...@yahoo.co.jp changed:

   What|Removed |Added

   Severity|normal  |regression


--- Comment #1 from kekeni...@yahoo.co.jp 2012-09-24 09:58:57 PDT ---
It is a regression in 2.060.

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


[Issue 8720] New: Assertion failure: '!vthis-csym' on line 727 in file 'glue.c'

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8720

   Summary: Assertion failure: '!vthis-csym' on line 727 in file
'glue.c'
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: purema...@zoadian.de


--- Comment #0 from Felix Hufnagel purema...@zoadian.de 2012-09-24 11:56:15 
PDT ---
C:\ResourceCompiler\RC.Exe /fo
C:\Users\suicide\Desktop\Flowd\Flowd\Flowd\obj\Debug\Win32Manifest.res
C:\Users\suicide\Desktop\Flowd\Flowd\Flowd\Resources\Win32Manifest.rc

Current dictionary: C:\Users\suicide\Desktop\Flowd\Flowd\Flowd

C:\D\dmd2\windows\bin\dmd.exe -gc -debug main.d obj\Debug\Win32Manifest.res
flowd.d  kernel32.lib gdi32.lib  -IC:\D\dmd2\src\druntime\import
-IC:\D\dmd2\src\phobos  -odobj\Debug
-ofC:\Users\suicide\Desktop\Flowd\Flowd\Flowd\bin\Debug\Flowd.exe 
-L/su:windows -L/exet:nt

Assertion failure: '!vthis-csym' on line 727 in file 'glue.c'

Exit code 1

Erzeugung abgeschlossen -- 1 Fehler, 0 Warnungen


Code dpaste or attachment:
Part 1:
http://dpaste.dzfl.pl/63ccc16c
Part 2:
http://dpaste.dzfl.pl/66116248


probably caused by this line:
auto filtered = this._flowConnections.filter!( (a)=(a.inputSlot !=
inputSlot))();

using dmd 2.60

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


[Issue 8721] New: std.algorithm.remove problem

2012-09-24 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8721

   Summary: std.algorithm.remove problem
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2012-09-24 17:13:09 PDT ---
This program works correctly, with output ABCEFG:


import std.stdio: writeln;
import std.algorithm: remove, SwapStrategy;
void main() {
dchar[] data = ABCDEFGd.dup;
data = remove!(SwapStrategy.stable)(data, 3);
writeln(data);
}



But this shows a wrong output GBCDEF:

import std.stdio: writeln;
import std.algorithm: remove, SwapStrategy;
void main() {
dchar[] data = ABCDEFGd.dup;
data = remove!(SwapStrategy.unstable)(data, 3);
writeln(data);
}


unstable means that the output order of the items is unspecified, but when I
give a single offset to remove from the array (that is by far the most common
use case for the remove() function, so maybe it's worth having a very efficient
overload for such case), I'd like it to just move the last item to the given
index position, producing: ABCGEF (and I'd this behavour to be written in the
docs of the remove() function, so programmers can rely on it).

Such semantics is fast and makes the remove() function more handy because most
times programmers use this strategy to manually remove one item from an array
when keeping the order is not important. So such semantics allows to use
remove() as drop-in replacement for that common manually written code.


This is an use case where this semantics is necessary, despite it's not needed
to keep the order of the items:


foreach_reverse (ref x; items)
foreach_reverse (ref y; items)
if (x != y  x.isIncluded(y)) {
x = items[$ - 1];
items.length--;
break;
}

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