[Issue 15959] core.sys.windows modules should be modified for x64

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15959

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

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from j...@red.email.ne.jp ---
Reopend.

I have a bad news and a good news.

BAD one:
The above list sucks absolutely.
Hundreds of DWORD_PTR, LONG_PTR, and INT_PTR are sprinkled over Windows SDK.
So we have to detect corresponding ones in our druntime and to fix.

GOOD one:
I've decided to carry out this task.
It is close to the end. :|

--

[Issue 16001] Lambda syntax: forbid use with FunctionLiteralBody: (x) => {assert(x);}

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16001

Xinok  changed:

   What|Removed |Added

 CC||xi...@live.com

--- Comment #1 from Xinok  ---
Further discussion here:
http://forum.dlang.org/thread/hjjbizewgoqkybycm...@forum.dlang.org

--

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #14 from safety0ff.bugz  ---
(In reply to Aleksei Preobrazhenskii from comment #13)
> 
> All suspending signals were delivered, but it seems that number of calls to
> sem_wait was different than number of calls to sem_post (or something
> similar). I have no reasonable explanation for that.
>
> It doesn't invalidate the hypothesis that RT signals helped with original
> deadlock though.

I haven't looked too closely at whether there's any races for thread
termination.
My suspicions are still on a low-level synchronization bug.
Have you tried a more recent (3.19+ kernel) or trying to newer glibc?

I'm aware of this bug [1] which was supposed to affect kernels 3.14 - 3.18 but
perhaps there's a preexisting bug which affects your machine?

[1] https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64

--

[Issue 16021] New: Template constraint bug

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16021

  Issue ID: 16021
   Summary: Template constraint bug
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@makechip.com

is(T : A!T) tells if T can automatically be converted to A!T.  The
last line below is doing just that, yet the template constraint does not work.

class A(T) if (is(T : A!T))
{
}

// if (is(T : A!T)) gives this error:
// Error: template instance x.A!(B) does not match
//template declaration A(T) if (is(T : A!T))
//while looking for match for A!(B)

class B : A!(B)
{
}

void main(string[] args)
{
B b = new B();
A!B a = b; // compiles fine
}

--

[Issue 16015] Sometimes importing a module both top-level and in a version(unittest) block causes some method overrides to be hidden

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16015

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

   What|Removed |Added

 CC||b2.t...@gmx.com
   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #4 from b2.t...@gmx.com ---
Also this doesn't happen when the import is not selective because then there's
no alias to the struct declared in the other module.

The problem is a very uninformative message, as you've noted, the conflict is
not detected when the struct declared in the second module is not a template.

--

[Issue 15831] IFTI voldemort type exploding bloat

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15831

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--

[Issue 16015] Sometimes importing a module both top-level and in a version(unittest) block causes some method overrides to be hidden

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16015

--- Comment #3 from Sophie  ---
The provided example fails to compile on OSX Mavericks with the same error.

--

[Issue 16014] Concatenated strings don't work in deprecation messages on module statements

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16014

--- Comment #5 from Jack Stouffer  ---
(In reply to Kenji Hara from comment #3)
> (In reply to Jack Stouffer from comment #2)
> > It could at least be made to work with string literals and manifest
> > constants, right?
> 
> I think it's not good to implement vulnerable behavior. It would just bloat
> compiler maintenance cost.

But this is already the behavior for everything but module declarations:

-
struct A
{
deprecated(""~"") int a;
}

void main()
{
A s;
s.a = 4;
}
-

$ dmd -run test.d

Deprecation: variable test.A.a is deprecated -

> By the way, do you have a concrete situation you would like to use
> contatenation, manifest constant, or other compile time constructed message
> for module deprecation?

Yes, in Phobos we are trying to enforce Phobos style guides via dscanner, and
we need this in order to make every line in Phobos less than 120 characters.

--

[Issue 16020] New: AliasDeclarationY doesn't allow to alias a function type

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16020

  Issue ID: 16020
   Summary: AliasDeclarationY doesn't allow to alias a function
type
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

std.typecons contains a load of C-ish alias declarations in the unittests.

The problem here is the new syntax that doesn't allow to declare the equivalent
without typing a silly declaration:

for example in typecons:

alias int F1();

the only way to get the same type alias using the most modern syntax is

import std.traits;
alias F1 = PointerTarget!(int function());

and

alias F1 = int();

is not allowed at all.


There's a **gap** because now we can't say "let's drop the old alias syntax
completly".

--

[Issue 16019] Implement a way to check GC usage stats from application

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16019

Dicebot  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--

[Issue 16019] New: Implement a way to check GC usage stats from application

2016-05-12 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16019

  Issue ID: 16019
   Summary: Implement a way to check GC usage stats from
application
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: pub...@dicebot.lv

The last remaining difference between our internal D2 compiler and vanilla
2.070 is addition of small stats function to runtime:

void gc_usage ( ref size_t used, ref size_t available );

We use it for two main cases:

1) verify GC usage of library utilities
2) doing live reporting of app performance in quick info console

Martin Nowak told it should be relatively easy to provide one (or similar)
based on existing internal stat system, thus exposing the enhancement request
to outer world.

--