date:20160511

[Issue 16018] New: fold size_t[] with int seed causes forward reference error

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16018

  Issue ID: 16018
   Summary: fold size_t[] with int seed causes forward reference
error
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

% cat test.d
import std.algorithm;
void foo(size_t[] shape)
{
shape[].fold!"a*b"(1);
}
% dmd test.d
std/traits.d(551): Error: forward reference of variable parentPrefix
std/traits.d(461): Error: template instance std.traits.fqnSym!(binaryFun) error
instantiating
std/algorithm/iteration.d(2680):instantiated from here:
fullyQualifiedName!(binaryFun)
std/algorithm/iteration.d(2661):instantiated from here:
reduceImpl!(false, ulong[], int)
std/algorithm/iteration.d(2645):instantiated from here:
reducePreImpl!(ulong[], int)
std/algorithm/iteration.d(3024):instantiated from here: reduce!(int,
ulong[])
test.d(4):instantiated from here: fold!(ulong[], int)
std/algorithm/iteration.d(2677): Error: static assert  __error
std/algorithm/iteration.d(2661):instantiated from here:
reduceImpl!(false, ulong[], int)
std/algorithm/iteration.d(2645):instantiated from here:
reducePreImpl!(ulong[], int)
std/algorithm/iteration.d(3024):instantiated from here: reduce!(int,
ulong[])
test.d(4):instantiated from here: fold!(ulong[], int)

works fine if you replace 1 with size_t(1)

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16015

--- Comment #2 from Sophie  ---
I was able to reproduce this error on Windows 7 and will try this specific test
on OSX Mavericks soon, but I expect the problem is not present on OSX.

Testing this requires two files:

test1.d

import test2 : mystruct;
import std.stdio : writeln;

struct anotherstruct{
int y = 0;
void testmethod(in int x){
writeln(x * this.y);
}
void testmethod(T)(in mystruct!T my){
writeln(my.x * this.y);
}
}

version(unittest) import test2 : mystruct;
unittest{
auto mine = mystruct!int(2);
auto another = anotherstruct(2);
another.testmethod(0); // compiles
another.testmethod(mine); // does not compile
}

test2.d

struct mystruct(T){T x;}

This is the resulting error:

E:\Dropbox\Projects\d\misc\test1.d(19): Error: none of the overloads of
'testmethod' are callable using argument types (mystruct!int), candidates are:
E:\Dropbox\Projects\d\misc\test1.d(6):   
test1.anotherstruct.testmethod(const(int) x)
Failed: ["dmd", "-IE:/Dropbox/Projects/d", "-debug", "-g", "-unittest",
"-v", "-o-", "E:\\Dropbox\\Projects\\d\\misc\\test1.d",
"-IE:\\Dropbox\\Projects\\d\\misc"]
[Finished in 0.3s with exit code 1]
[shell_cmd: rdmd -odbin/ -I"E:/Dropbox/Projects/d" -debug -g --main
-unittest "E:\Dropbox\Projects\d\misc\test1.d"]

If mystruct is not templated, then sensible descriptive errors occur letting me
know that I've aliased the imported "mystruct" twice, and if without the
template I just "import test2;" then everything compiles fine.

Removing "version(unittest) import test2 : mystruct;" from test1.d also allows
the problematic line to compile.

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #13 from Aleksei Preobrazhenskii  ---
I saw new deadlock with different symptoms today. 

Stack trace of collecting thread:

Thread XX (Thread 0x7fda6700 (LWP 32383)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
#1  0x007b4046 in thread_suspendAll ()
#2  0x007998dd in gc.gc.Gcx.fullcollect() ()
#3  0x00797e24 in gc.gc.Gcx.bigAlloc() ()
#4  0x0079bb5f in
gc.gc.GC.__T9runLockedS47_D2gc2gc2GC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS21_D2gc2gc10mallocTimelS21_D2gc2gc10numMallocslTmTkTmTxC8TypeInfoZ.runLocked()
()
#5  0x0079548e in gc.gc.GC.malloc() ()
#6  0x00760ac7 in gc_qalloc ()
#7  0x0076437b in _d_arraysetlengthT ()
...application stack

Stack traces of other threads:

Thread XX (Thread 0x7fda5cff9700 (LWP 32402)):
#0  0x7fda78927454 in do_sigsuspend (set=0x7fda5cff76c0) at
../sysdeps/unix/sysv/linux/sigsuspend.c:63
#1  __GI___sigsuspend (set=) at
../sysdeps/unix/sysv/linux/sigsuspend.c:78
#2  0x0075d979 in core.thread.thread_suspendHandler() ()
#3  0x0075e220 in core.thread.callWithStackShell() ()
#4  0x0075d907 in thread_suspendHandler ()
#5  
#6  pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:160
#7  0x00760069 in core.sync.condition.Condition.wait() ()
...application stack


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.

--

[Issue 16007] Some Win32 API structs has wrong definitions

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16007

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

   What|Removed |Added

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

--

[Issue 16007] Some Win32 API structs has wrong definitions

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16007

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/f0ba6561476c58b5bb66d214d7915ba6d889a960
Merge pull request #1570 from qchikara/pr-16007

fix Issue 16007 - Some Win32 API structs has wrong definitions

--

[Issue 15965] [REG 2.070] Reference to other CT-known field on struct instantiation now yields "circular reference"

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15965

--- Comment #3 from Dicebot  ---
I think it is one of few cases where immediate breakage is indeed legitimate.

--

[Issue 16017] package functions show up in std.experimental.allocator.common docs

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16017

Jack Stouffer  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All
   Severity|enhancement |normal

--

[Issue 16017] New: package functions show up in std.experimental.allocator.common docs

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16017

  Issue ID: 16017
   Summary: package functions show up in
std.experimental.allocator.common docs
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

There are at least 10 functions marked package that still show up in the docs
of std.experimental.allocator.common, for example:
http://dlang.org/phobos/std_experimental_allocator_common.html#.divideRoundUp

--

[Issue 16016] New: Remove std.concurrencybase from the docs

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16016

  Issue ID: 16016
   Summary: Remove std.concurrencybase from the docs
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

No reason for it to be there, it just causes confusion.

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16014

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

   What|Removed |Added

 CC||j...@red.email.ne.jp

--- Comment #4 from j...@red.email.ne.jp ---
One could simply put pragma message in that module.

module a;

pragma(msg, __FILE__,"(",__LINE__,"): this module is deprecated");

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16014

--- Comment #3 from Kenji Hara  ---
(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.

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?

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16014

--- Comment #2 from Jack Stouffer  ---
It could at least be made to work with string literals and manifest constants,
right?

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16014

--- Comment #1 from Kenji Hara  ---
Although the OP code is legitimate from the D grammar spec, there's not yet
proper definition/implementation for the semantic analysis.

I'm not sure how compiler should behave with:

deprecated(a.foo() ~ a.bar()) module a;

string foo() { /* some CTFEable code 1 */ }
string bar() { /* some CTFEable code 2 */ }



Note that if we replace module with struct:

deprecated(S.foo) struct S   // line 1
{
static foo() { return "hello"; }
}
alias P = S*;  // line 5


Current compiler prints:

test.d(1): Deprecation: struct test.S is deprecated
test.d(5): Deprecation: struct test.S is deprecated - hello

The use of S in custom message expression exposes incompletion of semantic
analysis process. It's bad behavior.

--

[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=15984

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
Summary|Interface contracts |[REG2.071] Interface
   |retrieve garbage instead of |contracts retrieve garbage
   |parameters  |instead of parameters

--- Comment #6 from Kenji Hara  ---
https://github.com/dlang/dmd/pull/5765

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16015

Sophie  changed:

   What|Removed |Added

   Hardware|x86 |x86_64
 OS|Mac OS X|Windows

--- Comment #1 from Sophie  ---
In retrospect, inability to reproduce the error seems to be due to having
originally encountered the error on Win7 and having attempted to reproduce
using a simpler example on OSX Mavericks. Reverting my code to the previous
erroneous state that failed to compile on Windows caused no errors on OSX. I
can try to come up with a concise example sometime later on for code that fails
to compile on Windows, when I have access to my Windows machine again.

--

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

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16015

  Issue ID: 16015
   Summary: Sometimes importing a module both top-level and in a
version(unittest) block causes some method overrides
to be hidden
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: meapineap...@gmail.com

See http://forum.dlang.org/post/uaxbzdfcgapcnbelc...@forum.dlang.org

Attempts to reproduce this error more concisely have been unsuccessful, either
the redundant imports resolve without error (e.g. import some_module
duplicated) or the compiler gives an error like "Error: alias
some_module.some_struct conflicts with alias some_module.some_struct" (e.g.
import some_module : some_struct duplicated). In short - both of those errors
are sensible and I haven't been able to pin down what caused the different
behavior in the code given in the linked post.

--

[Issue 14205] Document D compatibility with fork

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=14205

Sobirari Muhomori  changed:

   What|Removed |Added

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

--

[Issue 16006] Investigate adding fork() to std.process

2016-05-11 Thread via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=16006

Sobirari Muhomori  changed:

   What|Removed |Added

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

--

[Issue 16018] New: fold size_t[] with int seed causes forward reference error

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

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

[Issue 16007] Some Win32 API structs has wrong definitions

[Issue 16007] Some Win32 API structs has wrong definitions

[Issue 15965] [REG 2.070] Reference to other CT-known field on struct instantiation now yields "circular reference"

[Issue 16017] package functions show up in std.experimental.allocator.common docs

[Issue 16017] New: package functions show up in std.experimental.allocator.common docs

[Issue 16016] New: Remove std.concurrencybase from the docs

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

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

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

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

[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters

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

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

[Issue 14205] Document D compatibility with fork

[Issue 16006] Investigate adding fork() to std.process

18 matches

Site Navigation

Mail list logo

Footer information