[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17635

--- Comment #7 from Walter Bright  ---
The trouble with the getIndirection() is that passing a type:

  int*

and:

  struct S { int* p; }

behave differently. The first passes 'int' to traverseIndirections(), losing
the *, the second passes 'S', keeping the *.

There's just no way to make that work consistently. Kenji had papered it over,
which created the bug ag0ep6g found. But when I fixed that one, then this one
(from testInference.d) started passing when it should fail:

  struct S2 { const(int)* ptr; }
  immutable(S2) foo2b(const int*[] prm) pure { S2 s; return s; }

I can't make both work because of the getIndirection() inconsistency.

--

[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17635

--- Comment #6 from David Nadlinger  ---
(In reply to David Nadlinger from comment #5)
> After a quick glance, I'm not sure whether this is indeed what is at fault
> here. If it was indeed getIndirection() that was at fault, shouldn't it then
> also be used to decompose aggregate members in traverseIndirections?

Looking at my old changes, that used to indeed be the case, before I removed
the corresponding check in
https://github.com/dlang/dmd/commit/fa6898c3feb1c500085d73df716b9a1ce9e4afa1. 

It seems like my fix was indeed suboptimal/wrong, in that it left the code in
an overly conservative state, and I suppose it might be easier to start from
Kenji's original code again than from what I did.

--

[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17635

David Nadlinger  changed:

   What|Removed |Added

 CC||c...@klickverbot.at

--- Comment #5 from David Nadlinger  ---
After a quick glance, I'm not sure whether this is indeed what is at fault
here. If it was indeed getIndirection() that was at fault, shouldn't it then
also be used to decompose aggregate members in traverseIndirections? In other
words, wouldn't returning struct { T** } (or struct{ struct { T** } }, etc.)
instead of T** still falsely trip.

If I were to guess, I would say that traverseIndirections() is missing a
condition that returns false if the constness of the outermost layers is not
compatible instead of continuing to decompose the pointer types. That is, T*
and const(T*) should be regarded as a definite non-match, irrespective of what
T is. It seems like the previous `ta->immutableOf()->equals(tb->immutableOf())`
check did that, but with false positives.

--

[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17635

--- Comment #4 from Walter Bright  ---
Bug introduced by:

https://github.com/dlang/dmd/commit/f3b5817a3542f4fa4eb4a6e70658854e0d8e4aa3#diff-43282ebf5a2de5fdbcb3b5083ddf949dR3127

--

[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17635

--- Comment #3 from Walter Bright  ---
I found one of the problems in getIndirection() in func.d:

  extern (C++) Type getIndirection(Type t)
  {
t = t.baseElemOf();
if (t.ty == Tarray || t.ty == Tpointer)
return t.nextOf().toBasetype();
if (t.ty == Taarray || t.ty == Tclass)
return t;
if (t.ty == Tstruct)
return t.hasPointers() ? t : null; // TODO

// should consider TypeDelegate?
return null;
  }

https://github.com/dlang/dmd/blob/master/src/ddmd/func.d#L2459

The TODO means we're one level of indirection off, meaning all the rest of the
code that relies on getIndirection() is botched with structs, including
traverseIndirections(), which simply cannot work right with this error.

--

[Issue 17877] New: Missing library path in LDC settings

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17877

  Issue ID: 17877
   Summary: Missing library path in LDC settings
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: thomas.hedst...@mail.com

kernel32.lib is not found when compiling for LDC 32/64bit.

The reason seems to be that paths in the "LDC Directories" are only:
$(VCTOOLSINSTALLDIR)lib\x64
$(UCRTSdkDir)Lib\$(UCRTVersion)\ucrt\x64

but kernel32.lib is placed in:
$(UCRTSdkDir)Lib\$(UCRTVersion)\um\x64

Adding this third path, makes LDC work in my system.
Windows 10
VS2017 Community 15.3.5
VisualD v0.46.0-beta1

--

[Issue 17876] [REG 2.074] Internal error when comparing inout(Foo[][]) with Foo[][]

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17876

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com
  Component|phobos  |dmd
   Hardware|x86_64  |All
Summary|Internal error with red |[REG 2.074] Internal error
   |black tree of array of  |when comparing
   |arrays  |inout(Foo[][]) with Foo[][]
 OS|Linux   |All
   Severity|normal  |regression

--- Comment #2 from ag0ae...@gmail.com ---
Reduced (it's the result of using `binaryFun!"a < b"` in the `inout` method
`_firstGreaterEqual`):

bool _less(inout size_t[][] a, size_t[][] b) { return a < b; }


I don't know if this should compile or throw an error. Any way, it shouldn't
ICE.

dmd2.073.0 accepts the code, making this a regression.

Changing component to dmd as that's where the bug manifests as an ICE. The
actual bug might be in druntime.

--

[Issue 17876] Internal error with red black tree of array of arrays

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17876

--- Comment #1 from Christian Durán  ---
Probably just needs a better error message because it seems to happen because
there's no ordering for the type.

--

[Issue 17876] New: Internal error with red black tree of array of arrays

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17876

  Issue ID: 17876
   Summary: Internal error with red black tree of array of arrays
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ovejacuant...@gmail.com

Not sure if a problem with phobos or druntime.

import std.container.rbtree;
void main () {
auto a = redBlackTree!(size_t [][]);
}

With command 'dmd file' or 'ldc file' (DMD 2.076.0 and LDC 1.4.0) gives:

/usr/include/dlang/dmd/object.d(3462): Error: static assert  "Internal error."
/usr/include/dlang/dmd/std/functional.d-mixin-201(201):instantiated
from here: __cmp!(const(ulong[]), ulong[])
/usr/include/dlang/dmd/std/container/rbtree.d(866):instantiated from
here: binaryFun!(inout(ulong[][]), ulong[][])
/usr/include/dlang/dmd/std/container/rbtree.d(1832):instantiated from
here: RedBlackTree!(ulong[][], "a < b", false)

--

[Issue 17868] add pragma(crt_con/destructor[, priority])

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17868

--- Comment #6 from Martin Nowak  ---
(In reply to Rainer Schuetze from comment #4)
> This enables "system programming" by not adding every special case to the
> compiler as it is done so far.

It's a common enough use case to warrant a separate pragma.
Also just adding pointers to a section is not enough, the section needs to be
flagged accordingly for this to work (e.g. on OSX and ELF).
See WIP https://github.com/MartinNowak/dmd/tree/fix17868.

> Where custom args would vary based on what the compiler supports. This way, 
> the ctr_constructor part is standardized, but the custom args obviously 
> depend on support from the specific compiler. Use version statements as 
> needed.

Version statements for pragmas are a pain, you need to add a forwarding
function or repeat the implementations.

version (DMD)
   pragma(constructor, 1234)
   void func() { /* repeat */ }
else
   pragma(constructor)
   void func() { /* repeat */ }

Pragma arguments don't expand AliasSeq tuples, so that cannot be used either.

Also priority support is platform/linker dependent, not compiler dependent.
IMO simply making it only do sth. on supported platforms is an easy solution to
this.

I'd rather drop support for priorities instead of complicating the usage,
leaving priorities to GDC/LDC's non-standard intrinsics. We're not that likely 
to ever need it, but then again it would be cheap to just implement it right
away, and someone coming from C/C++ might want to use it.

--

[Issue 17869] scope class object no longer deleted when created via factory function

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17869

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 17868] add pragma(crt_con/destructor[, priority])

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17868

--- Comment #5 from Steven Schveighoffer  ---
I've changed my mind a bit on this. It's OK to have a pragma that allows
stuffing function pointers into a section for compiler purposes, obviously we
already have custom pragmas anyway.

But I still am leary of adopting the "integer priority" as an official API for
it.

What may be better is:

pragma(ctr_constructor[, custom args])

Where custom args would vary based on what the compiler supports. This way, the
ctr_constructor part is standardized, but the custom args obviously depend on
support from the specific compiler. Use version statements as needed.

--

[Issue 17415] std.conv.emplace does not forward arguments correctly

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17415

--- Comment #2 from Eduard Staniloiu  ---
I might be wrong, but since you are disabling the postblit wouldn't you want to
define the class ctor as:

class C
{
this(const ref S) { /* magic */ }
}

--

[Issue 17875] New: Range violation in std.regex

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17875

  Issue ID: 17875
   Summary: Range violation in std.regex
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

import std.regex;
import std.array;
import std.stdio;

unittest {
auto f = `abc`;
auto re = `(()|(.+))`;
writeln(f.matchAll(re)); // Line 8
writeln(f.matchAll(re).array); // Line 9
}

In the above example, line 9 fails with:

core.exception.RangeError@D:\github\phobos\std\regex\package.d(576): Range
violation

Changing the order of line 8 and 9, the problem disappears. Duplicating line 8
causes no exception.

The regex is shortened to the smallest I found that exhibits this behavior.

--

[Issue 17868] add pragma(crt_con/destructor[, priority])

2017-10-04 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17868

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #4 from Rainer Schuetze  ---
I guess these construction/destruction mechanisms are a special case of putting
function pointers into specific sections of the data segment. I'd prefer to not
implement the special case, but the more general
https://issues.dlang.org/show_bug.cgi?id=16300

This enables "system programming" by not adding every special case to the
compiler as it is done so far.

--