[Issue 17132] Using DLL makes an empty stacktrace on error

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17132

j...@red.email.ne.jp changed:

   What|Removed |Added

   Keywords||dll

--


[Issue 17132] Using DLL makes an empty stacktrace on error

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17132

--- Comment #1 from j...@red.email.ne.jp ---
The reason is that each dlls and app initialize the own druntime (and
stacktrace modules)
though the Windows' DBGHELP does not allow to initialize *more than once*.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681351(v=vs.85).aspx

So the latter initialization for app fails, leaving the initialized flag false.


QUICK WORKAROUND:
at core.sys.windows.stacktrace: shared static this()

dbghelp.SymCleanup(hProcess); // @@@ ADD
if (!dbghelp.SymInitialize(hProcess, generateSearchPath().ptr, TRUE))
return;

NOTE:
For now, we cannot raise exceptions over DLL boundary.
So I've no idea how to solve this correctly.

--


[Issue 17132] New: Using DLL makes an empty stacktrace on error

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17132

  Issue ID: 17132
   Summary: Using DLL makes an empty stacktrace on error
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

I am working with DLL in Windows.
When some error raises, the stacktrace always generates empty.

Probably, this is a Windows issue.

--


[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #13 from Jakub Łabaj  ---
I understand now, thanks!

You can find my profile here: https://github.com/byebye. I've create a simple
PR:  https://github.com/dlang/phobos/pull/5040 for similar issue involving
formattedRead, where I was wondering if I should restrict arguments to
pointers. So it seems the solution would be exactly the same in both cases.

--


[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #12 from Andrei Alexandrescu  ---
@Jakub, what's your github id? thx!

--


[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #11 from Andrei Alexandrescu  ---
Oh, sorry. The idea is to leave readf unqualified and let the compiler infer
whether it's safe or not.

In this particular case I see there's a simple solution - just add a constraint
to it making sure all parameters are pointers. Something like:

uint readf(Data...)(in char[] format, Data data)
if (allSatisfy!(isPointer, Data);

Then the only way to call readf is with pointers, which eliminates the
possibility of shenanigans.

--


[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #10 from Jakub Łabaj  ---
I know how to create PRs, I've already created some. What I mean is I'm not
sure how you see the solution, e.g. '@safe function with a small @trusted
core', could elaborate on this, please?

--


[Issue 17131] New: [Reg 2.074] Fiber.state collides with differently attributed function in derived class

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17131

  Issue ID: 17131
   Summary: [Reg 2.074] Fiber.state collides with differently
attributed function in derived class
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu
CC: slud...@outerproduct.org

cat > bug.d << CODE
import core.thread;

class TaskFiber : Fiber {
this() { super({}); }
State state() @trusted const nothrow { return super.state; }
}
CODE

dmd -c -o- bug

bug.d(7): Error: function bug.TaskFiber.state cannot override final function
core.thread.Fiber.state


Introduced (triggered?) by changing the attributes on
core.thread.Fiber.state().
https://github.com/dlang/druntime/pull/1726

Currently breaks vibe.d and a couple of projects on https://ci.dawg.eu.

--


[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17130

Martin Nowak  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |regression

--- Comment #1 from Martin Nowak  ---
Currently breaks vibe.d and a couple of projects on ci.dawg.eu.

--


[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8471

--- Comment #9 from Andrei Alexandrescu  ---
(In reply to Jakub Łabaj from comment #8)
> Sorry, I'm not sure what you mean by that - what are the next steps to do
> here?

I think Razvan Nitu has reached out to you on how to go about creating PRs.

--


[Issue 17130] New: [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17130

  Issue ID: 17130
   Summary: [Reg 2.074] ambiguous implicit super call when
inheriting core.sync.mutex.Mutex
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
import core.sync.mutex : Mutex;

class MyMutex : Mutex
{
}
CODE

dmd -c -o- bug


/home/dawg/Code/D/bug.d(3): Error: core.sync.mutex.Mutex.__ctor called with
argument types () matches both:
/home/dawg/dlang/dmd-master-2017-01-28/linux/bin64/../../src/druntime/import/core/sync/mutex.di(21):
core.sync.mutex.Mutex.this()
and:
/home/dawg/dlang/dmd-master-2017-01-28/linux/bin64/../../src/druntime/import/core/sync/mutex.di(25):
core.sync.mutex.Mutex.this()
/home/dawg/Code/D/bug.d(3): Error: class bug.MyMutex cannot implicitly generate
a default ctor when base class core.sync.mutex.Mutex is missing a default ctor


Introduced by https://github.com/dlang/druntime/issues/1728 or
https://github.com/dlang/druntime/issues/1726.

This is arguable a dmd bug, but it easily breaks any Mutex sub-class right now.

--


[Issue 17057] trait "allMembers" incorrectly includes imports

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17057

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/912252b50277b95964981ef197d708db662b6554
Fix Issue 17057 - Added test file

https://github.com/dlang/dmd/commit/6280bb4437c05f418e852dad65c7f09ae2b43dd7
Merge pull request #6505 from RazvanN7/Issue_17057

Fix Issue 17057 - trait allMembers incorrectly includes imports

--


[Issue 17057] trait "allMembers" incorrectly includes imports

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17057

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--


[Issue 17129] New: class-nested alias of free function can't be called from const-methods

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17129

  Issue ID: 17129
   Summary: class-nested alias of free function can't be called
from const-methods
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dl...@supradigital.org

The following code fails with this compiler message:

main.d(11): Error: template main.C.filter!((a) => a != 0).filter cannot deduce
function from argument types !()(int[]) const, candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(1057):   
main.C.filter!((a) => a != 0).filter(Range)(Range range) if
(isInputRange!(Unqual!Range))



import std.algorithm;

alias filterZeros2 = filter!(a=>a!=0);

class C
{
alias filterZeros = filter!(a=>a!=0);

void doCount ( ) const
{
filterZeros([1,2,3]).count;  // fails
filterZeros2([1,2,3]).count; // works
}

void doCount ( )
{
filterZeros([1,2,3]).count; // works
filterZeros2([1,2,3]).count; // works
}
}

void main() {}

--


[Issue 16521] Wrong code generation with switch + static foreach

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16521

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

 CC||4bur...@gmail.com

--- Comment #2 from Nemanja Boric <4bur...@gmail.com> ---
I hit the same bug today:

```
import std.traits;

struct S
{
int a, b, c, d, e, f;
}

void main()
{
S s;

foreach (name; ["a", "b", "c"])
{
switch (name)
{
foreach (i, ref field; s.tupleof)
{
case __traits(identifier, S.tupleof[i]):
field = 0; // s.tupleof[i] = 0; works
break;
}
default:
break;
}
}
}
```

--


[Issue 17128] Wrong destructor call, if variables declared using tuple of types.

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17128

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--


[Issue 17128] New: Wrong destructor call, if variables declared using tuple of types.

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17128

  Issue ID: 17128
   Summary: Wrong destructor call, if variables declared using
tuple of types.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: jappleg...@gmail.com

import std.stdio;
struct Foo {
int val = 0;
~this() {
writefln("destruct %s", val);
}
}

void bar(ARGS...)() {
ARGS args;
args[0].val = 1;
writefln("val = %s", args[0].val);
}

void main() {
bar!Foo();
}

Excpected output:
val = 1
destruct 1

But got:
destruct 0
val = 1

It seems that the compiler destructs 'args' immediately after definition, not
at the end of the function.

--


[Issue 17127] New: bad example code for std.concurrency.Generator

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17127

  Issue ID: 17127
   Summary: bad example code for std.concurrency.Generator
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Found by Profile Anaysis who posted to D.learn:
http://forum.dlang.org/post/vlvqmzrfvqmxzsfxp...@forum.dlang.org

The example code for std.concurrency.Generator [1] throws an OwnerTerminated
exception. The code:


import std.concurrency;
import std.stdio;


void main()
{
auto tid = spawn(
{
while (true)
{
writeln(receiveOnly!int());
}
});

auto r = new Generator!int(
{
foreach (i; 1 .. 10)
yield(i);
});

foreach (e; r)
{
tid.send(e);
}
}


The exception gets thrown because the spawned thread still tries to receive
ints after the main thread has finished. The example code should be fixed.


[1] https://dlang.org/library/std/concurrency/generator.html

--


[Issue 12894] Make extern(Windows) behave like extern(C) on non-Windows systems

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12894

anonymous4  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #5 from anonymous4  ---
UnixODBC uses windows calling convention on non-Windows systems.

--


[Issue 17118] [REG 2.074a] iasm64.d in test suite with with -g reveals a regression

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17118

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from b2.t...@gmx.com ---
contact uplink.co...@googlemail.com to get a clean report.
This was reported indirectly.

--


[Issue 14932] The language specification does not define what the shared attribute does

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14932

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16198

--


[Issue 16198] Language specification should have a page about concurrency

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16198

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14932

--