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

2018-08-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #23 from Jonathan M Davis  ---
And this is my PR with the binding changes that are required to get the
druntime and Phobos unit tests and the dmd test suite passing:

https://github.com/dlang/druntime/pull/2280

(In reply to Martin Nowak from comment #22)
> What happened to the idea of runtime compat checks mentioned in comment 9?
> In particular it seems that FreeBSD's dealing with the ABI change in C
> should be fully understood before taking any measures.
> Also there are versioned symbols in FBSD12 that use the old struct layouts
> (e.g. `stat@FBSD_1.0`). We could always use those for now.
> As another option you might use the new functions and struct layouts if
> running on >=12, but translate the structs to the old layout and explicitly
> call the old versioned symbols if running on <12.

Rather than repeating myself, I'll let anyone read the discussion in the dmd PR
to get the full answer to that.

--


[Issue 18078] [CTFE] wrong initialization of array member with inout opIndex

2018-08-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18078

ag0aep6g  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--


[Issue 19097] Extend Return Scope Semantics

2018-08-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19097

--- Comment #5 from Walter Bright  ---
(In reply to Mike Franklin from comment #4)
> How does `return` apply to a function that has no `return` type?

If the return type is 'void', and the first parameter is by 'ref', the 'return'
applies to the first parameter. That's the whole thing in one sentence.

(For member functions, the first parameter is the implicit 'this' reference.)

--


[Issue 19097] Extend Return Scope Semantics

2018-08-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19097

--- Comment #4 from Mike Franklin  ---
> This situation comes up repeatedly with:
> 1. constructors
> 2. property setters
> 3. put(dest, source) functions

In other words 2 and 3 are functions that return `void`.  Constructors are like
`static` functions that return an object instance, so I'm not sure how the
problem at hand applies to constructors.

> Annotating a parameter with `return` has been quite successful at tracking
scope dependencies from the parameter to the function return value.

The problem with that is we don't have sufficient documentation describing the
semantics of `return` parameters and their relationship with `scope`.  So, I
can't understand how `return` has been used in the past to solve such issues.

So `betty` returns `void`, but a `return` parameter transfers its lifetime to
the function return value.  So I guess that's the nature of this issue.  How
does `return` apply to a function that has no `return` type?

--


[Issue 19097] Extend Return Scope Semantics

2018-08-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19097

--- Comment #3 from Mike Franklin  ---

Example 2
-
@safe:

void betty(ref scope int* r, return scope int* p) 
{ 
r = p; // (1) Error: scope variable `p` assigned to `r` with longer
lifetime
} 

void main()
{
int* p;
int i;
int* q;

betty(q, ); // (2) ok
betty(p, ); // (3) should be error
}

Compile with -dip1000:  https://run.dlang.io/is/t6wj71

So, I'm assuming (1) should not be an error because it depends on the lifetimes
of the arguments supplied by the caller.  Correct?

--


[Issue 19097] Extend Return Scope Semantics

2018-08-18 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=19097

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #2 from Mike Franklin  ---
Trying to dissect Walter's back-of-the-napkin description:

Example 1
-
@safe:

int* frank(return scope int* p) { return p; }

void main()
{
// lifetimes end in reverse order from which they are declared
int* p;  // `p`'s lifetime is longer than `i`'s
int i;   // `i`'s lifetime is longer than `q`'s
int* q;  // `q`'s lifetime is the shortest

q = frank(); // ok because `i`'s lifetime is longer than `q`'s
p = frank(); // error because `i`'s lifetime is shorter than `p`'s
}

This works in the compiler today if both functions are declared @safe and if
compiled with -dip1000:  https://run.dlang.io/is/CZ3YuU

--