[Issue 16049] New: core.sys.windows structs have wrong sizes and aligns

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

  Issue ID: 16049
   Summary: core.sys.windows structs have wrong sizes and aligns
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

core.sys.windows.* modules came with 2.070.
I'm verifying sizes of the structs by comparing with ones in Windows SDK
headers.

So, I found that many have wrong sizes and/or field alignments.
These problems would make runtime error.
Most of them are in Win64 environment.

I'll send a PR later.

--

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

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

--- Comment #8 from j...@red.email.ne.jp ---
#1552 #1575 was merged, thanks.

But #1574 remains. ( which has the most fixes )

--

[Issue 15607] [ICE] CTFE internal error: bad compare on accessing default-initialized static immutable array of array

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #7 from Walter Bright  ---
(In reply to Mathias Lang from comment #5)
> This segv all the same:
> 
> ```
> private static immutable char[2][ubyte.max + 1] code_base = [ "??" ];
> ```
> 
> and so does:
> 
> ```
> private static immutable char[2][ubyte.max + 1] code_base = [ [ '?', '?' ] ];
> ``

Neither of these seg fault when I put them in a file and compile them.

--

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

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

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

https://github.com/dlang/druntime/commit/fa93b0b2ac3214f020c7f96859c5dcfd61fbff9b
Merge pull request #1575 from qchikara/pr-size_t

More fix of issue 15959 (size_t)

--

[Issue 16039] DMD produces huge binary when using a complex chain of lazy range algorithms

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |DUPLICATE

--- Comment #1 from Steven Schveighoffer  ---
Thanks. This is a duplicate of 15831

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

--

[Issue 15831] IFTI voldemort type exploding bloat

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||geor...@outlook.com

--- Comment #3 from Steven Schveighoffer  ---
*** Issue 16039 has been marked as a duplicate of this issue. ***

--

[Issue 16048] New: std.getopt: duplicated (short) options are not detected

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

  Issue ID: 16048
   Summary: std.getopt: duplicated (short) options are not
detected
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: andrej.mitrov...@gmail.com

If you have multiple config options such as:

-
getopt(args, "arg1|a", , "arg2|a", );
-

Getopt won't complain about this, and will parse all 'a' options into arg1.

--

[Issue 16047] New: Range violation in setting multi-dimensional AA entries

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

  Issue ID: 16047
   Summary: Range violation in setting multi-dimensional AA
entries
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kroepli...@googlemail.com

The following code results in a range violation for the second assignment to
`aa`, while the first assignment to `aa` works as expected:

unittest
{
import std.datetime;

struct S
{
   string s;

   this(string s)
   {
   this.s = s;
   }
}

SysTime[string][string] aa;

aa["bar"]["bar"] = SysTime.init;
aa[S("baz").s]["baz"] = SysTime.init;  // Range violation
}

Any further reduction of the example eliminates the issue.

--

[Issue 16037] Closure allocation despite scope variable for ternary operator / CondExp

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

Leandro Lucarella  changed:

   What|Removed |Added

 CC||leandro.lucarella@sociomant
   ||ic.com

--

[Issue 16046] New: ScopedAllocator does not set prev, causing segfaults

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

  Issue ID: 16046
   Summary: ScopedAllocator does not set prev, causing segfaults
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: initrd...@gmail.com

This code causes a segfault:

ScopedAllocator!MmapAllocator alloc;
auto foo = alloc.make!int(1).enforce;
auto bar = alloc.make!int(2).enforce;
alloc.dispose(foo);
alloc.dispose(bar); // segfault here

This is likely because ScopedAllocator.allocate does not set the prev pointer
of the old root when prepending a new node, so prev will always be null.

--

[Issue 16045] New: Unable to loading global variables in inline assembly with -fPIC

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

  Issue ID: 16045
   Summary: Unable to loading global variables in inline assembly
with -fPIC
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

Consider the following source file `asm_pic.d`:

align(16) static immutable short[8] A = [ 1, 1, 1, 1, 3, 3, 3, 3 ];

void main()
{
asm
{ 
pmullw XMM0, A;
}
}

LDC 1.0.0-b1 thinks it's compatible with PIC code.

```bash
$ ldc2 asm_pic.d # ok
$ ldc2 -relocation-model=pic asm_pic.d # ok
```

DMD disallows to load the constant in PIC code.


$ dmd asm_pic.d  # ok
$ dmd -fPIC asm_pic.d  # fail
asm_pic.d(7): Error: cannot directly load global variable 'A' with PIC code

--

[Issue 12936] Some more @nogc cases for immediately iterated array literal

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86 |All
 OS|Windows |All

--- Comment #2 from Kenji Hara  ---
(In reply to bearophile_hugs from comment #0)
> 
> struct F { int x; }
> void main() @nogc {
> foreach (   a; [F(1)]) {}   // Case#1 OK
> foreach (int[1] a; [[1]]) {}// Case#2 Error
> foreach (const ref int[1] a; [[1]]) {}  // Case#3 Error
> foreach (   a; [[1]]) {}// Case#4 Error
> }

For case#2, it's possible enhancement because int[1] a is a copy of iterated
array literal element.

For case#3, it's not safe because an address of stack allocated array literal
can escape out of the lifetime.

const(int)* p;
foreach (const ref int[1] a; [[1]]) { p = [0]; }
// After the foreach, p wold point invalid stack address.

Note that similar situation is properly rejected.

void foo(ref int[1] sa) {}
void main() {
foo([1]);   // array literal never become stack allocated because
// its address can escape out via the ref parameter.
}

For case#4 supporting it would cause inconsistent type inference result.

void foo() {
foreach (a; [[1]]) { pragma(msg, typeof(a)); }  // prints int[]
}
void bar() @nogc {
foreach (a; [[1]]) { pragma(msg, typeof(a)); }  // prints int[] or
int[1]?
}

I opened a compiler improvement for case#2:
https://github.com/dlang/dmd/pull/5795

--

[Issue 16034] map should be possible with a reference only

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #2 from ZombineDev  ---
IMO, the language limitation that ref is not part of the type (but is instead
only a storage class), prevents making ranges work (among other things) work
with non-copyable types.
If that wasn't the case ElementType!(One[]) could return ref(One), and you
could use map with a lambda whose paramter is ref(One).

--

[Issue 7446] [TDPL] Trivial asynchronous file copy example crashes with OwnerTerminated

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

Xiao Di Guan  changed:

   What|Removed |Added

 CC||x...@puxlit.net

--