[Issue 17751] Internal error: ddmd/backend/el.c 2927

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #2 from Iain Buclaw  ---
Seems like a strange limitation, but it's your intrinsic.

--

[Issue 17751] Internal error: ddmd/backend/el.c 2927

[d-bugmail--- via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7216

The imm8 needs to go into the template parameter list as a constant.

--

[Issue 17891] forum is dog slow

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from ki...@gmx.net ---
(In reply to Steven Schveighoffer from comment #3)
> Is there something to do with the GC running (assuming these are all backed
> by D code)? That would fit the pattern.

I silently hoped this wouldn't be the case - if that's the reason, it'd be a
prime example where the current GC fails badly.

--

[Issue 17896] Alternate version of std.conv.to which returns Nullable

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Jonathan M Davis  ---
(In reply to Steven Schveighoffer from comment #3)
> Anything that uses opCast is circumventing to's builtin mechanisms anyway as
> to defers to the type "It knows better than me". It's no different here.

As far as std.conv.to goes, opCast is just a way for the type to codify a
conversion to another type - the same as constructors except that that defines
how to convert to the type instead of from it.

But regardless, we're talking about adding a way to attempt a conversion and
have it return Nullable if the conversion fails, and if the type casts to
Nullable!int, it likely means something else other than the cast attempted to
convert to int and failed. We have no idea what the person who created that
opCast meant without looking at its documentation. It could have entirely
different semantics.

I really think that it's asking for trouble to try and make std.conv.to do
double-duty here and conflate converting to Nullable!T in general as being an
attempt to convert to T that failed as opposed to having a specific function
that's explicitly designed to return Nullable where null indicates a failure
instead of using an exception.

I also think that special-casing Nullable!T for to will make it more confusing
for folks reading, because it's a non-obvious behavior, especially since to has
never worked that way before, whereas a separate function makes it clear.

Without adding a function in addition to opCast that tryTo would then look for
on a user-defined type to attempt a conversion (one which returns Nullable!T
like tryTo), we probably will have to wrap a call to opCast and catch
ConvException if opCast is how the conversion is done so that we can avoid
having tryTo throw a ConvException due to opCast using std.conv.to internally,
but either way, I think that assuming that the fact that opCast returns a
Nullable!T means that it's attempting to convert to T and failing like tryTo
would is a bad plan, regardless of how much sense it does or doesn't make to
special case to!(Nullable!T) otherwise. It's assuming semantics that may not
exist and certainly have not officially existed previously.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

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

alex.jercai...@gmail.com changed:

   What|Removed |Added

 CC||alex.jercai...@gmail.com
   Assignee|nob...@puremagic.com|alex.jercai...@gmail.com

--- Comment #11 from alex.jercai...@gmail.com ---
Hi, I can take a look into this

--

[Issue 17896] Alternate version of std.conv.to which returns Nullable

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Steven Schveighoffer  ---
Anything that uses opCast is circumventing to's builtin mechanisms anyway as to
defers to the type "It knows better than me". It's no different here.

struct S1
{
   string s;
   auto opCast(T : Nullable!int)() { return customizedConversion(); }
}

struct S2
{
   string s;
   auto opCast(T : int)() { return customizedConversion(); } // can throw
}

void main()
{
   S1 s1;
   S2 s2;
   auto x = s1.to!(Nullable!int); // s1.opCast!(Nullable!int)
   auto y = s2.to!(Nullable!int); // Nullable!int _tmp; try { _tmp =
s2.opCast!int; } catch {}; y = _tmp;
}

And of course, normal builtins cast to Nullable!T should not do a throw and
catch, but optimize that out.

--

[Issue 17897] Incorrect number of destructor calls in example

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #8 from Steven Schveighoffer  ---
I don't know if it's in the spec or not, but clearly, there is no reason for
the temporary not to be constructed in-place on the stack for passage into fun.
It does not need to construct it and then make a copy, that would be wasteful.

Yes, the ultimate guarantee is that the number of postblits/ctor calls must
equal the number of dtor calls. But the bug is definitely that an extra dtor
call is made.

Compiling with -vcg-ast shows no such call, I only see one. The extra dtor is
completely erroneous.

--

[Issue 17897] Incorrect number of destructor calls in example

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from Jack Applegame  ---
(In reply to Steven Schveighoffer from comment #5)
> The bug in the example is that the destructor is called twice, not that
> postblit is not called.
Not exactly. In fact, it is important that the number of constructor calls was
equal to the number of destructors calls (as Richard said). So this bug can be
interpreted as missed postblit or extra destructor.
I believe that the compiler is free to choose to make a copy or not.
Or am I mistaken and the exact behavior is somewhere in specs?

--

[Issue 17897] Incorrect number of destructor calls in example

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from Steven Schveighoffer  ---
Expected should read:
Bar.this(int): 
fun: 
Bar.~this(): 

--

[Issue 17897] Incorrect number of destructor calls in example

[d-bugmail--- via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Postblit is not called for  |Incorrect number of
   |temporary structures in the |destructor calls in example
   |function parameters |

--- Comment #5 from Steven Schveighoffer  ---
The bug in the example is that the destructor is called twice, not that
postblit is not called.

I assumed you were going to file a bug on the destructor calls, but looks like
this is it, so I'll just change the title.

(In reply to Simen Kjaeraas from comment #4)
> (In reply to Steven Schveighoffer from comment #1)
> As we can see for unittest1, the destructor is called twice - once for the
> temporary in the unittest block, and once when  we exit fun().

No, it's called once for the local in fun, and another time for no reason (an
actual bug). It's still a move.

--

[Issue 17897] Postblit is not called for temporary structures in the function parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Simen Kjaeraas  ---
(In reply to Steven Schveighoffer from comment #1)
> Postblit is not called for moves.

You're misreading the bug report (not surprising, as it was marked
incorrectly). Expanded example:

import std.stdio;

struct Foo {
this(int) {}
~this() {}
}

struct Baz {}

struct Bar(T) {
this(T a) {
writefln("Bar.this(T): %X", );
}
this(T a, T b) {
writefln("Bar.this(T, T): %X", );
}
~this() {
writefln("Bar.~this(): %X", );
}
}

void fun(T)(Bar!T n) {
writefln("fun: %X", );
}

unittest { // 1
// Basically what Jack posted:
int n;
writefln("\nunittest 1: %X", );
fun(Bar!Foo(Foo(0), Foo(0)));
}

unittest { // 2
// Single Foo in Bar's constructor:
int n;
writefln("\nunittest 2: %X", );
fun(Bar!Foo(Foo(0)));
}

unittest { // 3
// Saving Foo(0) to a temporary:
int n;
writefln("\nunittest 3: %X", );
auto foo = Foo(0);
fun(Bar!Foo(foo, foo));
}

unittest { // 4
// using a type without constructor and destructor:
int n;
writefln("\nunittest 4: %X", );
fun(Bar!Baz(Baz(), Baz()));
}

Which gives this output:

unittest 1: 19FDAC
Bar.this(T, T): 19FDB3
fun: 19FD80
Bar.~this(): 19FD80
Bar.~this(): 19FDB3

unittest 2: 19FDB4
Bar.this(T): 19FDB8
fun: 19FD8C
Bar.~this(): 19FD8C

unittest 3: 19FDA8
Bar.this(T, T): 19FDAD
fun: 19FD7C
Bar.~this(): 19FD7C

unittest 4: 19FDB8
Bar.this(T, T): 19FDBC
fun: 19FD94
Bar.~this(): 19FD94

As we can see for unittest1, the destructor is called twice - once for the
temporary in the unittest block, and once when  we exit fun().

This is caused by some interaction with Foo's constructor and destructor, as
evinced by the fact that commenting out either fixes the problem (see unittest
4). Other things that fixes it include changing Bar's constructor to take a
single Foo instead of two (as seen in unittest 2), and saving Foo(0) to a
temporary before passing it to Bar() (as seen in unittest 3).

--

[Issue 17897] Postblit is not called for temporary structures in the function parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

Richard Cattermole  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Richard Cattermole  ---
(In reply to Steven Schveighoffer from comment #2)
> Sorry, I didn't mean to commit so early.
> 
> A postblit is not called for a move, which is done for rvalues being sent
> into a function:

snip

Except this isn't just a move.

No, the number of destructor calls must be equal to the number of
constructor/postblit calls. Otherwise reference counting types are not going to
work.

Postblit must be called in the given example.

Count: 1 - create
Count: 1 - fun call
Count: 0 - destructor (deallocate memory)
Count: segfault, memory has already been freed - destructor (deallocate memory)

Something is still wrong in the given example.

--

[Issue 17897] Postblit is not called for temporary structures in the function parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
Sorry, I didn't mean to commit so early.

A postblit is not called for a move, which is done for rvalues being sent into
a function:

import std.stdio;
struct S
{
   this(this) { writeln("postblit"); }
}

void foo(S s)
{
}

void main()
{
   foo(S()); // no postblit, this is an rvalue. The struct isn't actually moved
anyway.
   S s;
   foo(s); // postblit called, because we made a copy of s onto the stack to
send into foo.
}

--

[Issue 17897] Postblit is not called for temporary structures in the function parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |INVALID
Summary|Postbit is not called for   |Postblit is not called for
   |temporary structures in the |temporary structures in the
   |function parameters |function parameters

--- Comment #1 from Steven Schveighoffer  ---
Postblit is not called for moves.

--

[Issue 17497] [REG] OSX: tar.xz doesn't decompress correctly (from http://dlang.org/download.html)

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
Weird, clearly shows up as `XZ compressed data` on my Linux box and also
unpacks with `tar -Jtf dmd.2.074.1.osx.tar.xz`.
Can't really test this as my OSX machine still is on 10.8 and doesn't have
built-in tar.xz support (only added CLI support via
http://macpkg.sourceforge.net/).

Could you please retest and check whether that is still an issue with current
downloads, and whether 2.074.1 reproducibly fails?

That tar archives are packed and compressed on the host machine, so there might
have been tar/xz updates.

--

[Issue 17897] Postbit is not called for temporary structures in the function parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

Richard Cattermole  changed:

   What|Removed |Added

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

--

[Issue 17897] Postbit is not called for temporary structures in the function parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

Richard Cattermole  changed:

   What|Removed |Added

 CC||alphaglosi...@gmail.com
Summary|Зostbit is not called for   |Postbit is not called for
   |temporary structures in the |temporary structures in the
   |function parameters |function parameters

--

[Issue 17897] New: Зostbit is not called for temporary structures in the function parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17897
   Summary: Зostbit is not called for temporary structures in the
function parameters
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: jappleg...@gmail.com

Test case:

import std.stdio;

struct Foo {
this(int) {}
~this() {}
}

struct Bar {
this(this) {
writefln("Bar.this(this): %X", );
}
this(Foo, Foo) {
writefln("Bar.this(int): %X", );
}
~this() {
writefln("Bar.~this(): %X", );
}
}

void fun(Bar n) {
writefln("fun: %X", );
}

void main() {
Foo foo;
fun(Bar(foo, Foo(0)));
}

Result:

Bar.this(int): 
fun: 
Bar.~this(): 
Bar.~this(): 

Expected:

Bar.this(int): 
Bar.this(this): 
fun: 
Bar.~this(): 
Bar.~this(): 

Discussion: https://forum.dlang.org/post/tvzwzrpwadobzsxca...@forum.dlang.org

--

[Issue 7957] std.functional untuple/untupleReversed too

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/phobos/pull/5780

--

[Issue 17833] compiling dmd on x86 linux fails

[d-bugmail--- via Digitalmars-d-bugs]

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

Andreas Baumann  changed:

   What|Removed |Added

 CC||abaum...@yahoo.com

--- Comment #1 from Andreas Baumann  ---
See also https://bbs.archlinux32.org/viewtopic.php?id=65

--