Abstract

In short, the compiler internally annotates ref-return functions with ref(i1,...,iN) indicating that the function may return argument j (j=i1...iN) by reference (possibly via field accesses), where j is also a ref input argument. This list can be empty, and if the function is a method or internal function, argument 0 refers to implicit 'this' parameter. These annotations are used to validate/invalidate ref return functions that call such a ref return function. These annotations are also written in the automatically generated di interface files.

See the DIP38 for more details and examples.

On Mon, 06 May 2013 14:52:23 -0400, Timothee Cour <thelastmammoth@gmail.com> wrote:

> Abstract
>
> In short, the compiler internally annotates ref-return functions with
> ref(i1,...,iN) indicating that the function may return argument j
> (j=i1...iN) by reference (possibly via field accesses), where j is
> also a ref input argument. This list can be empty, and if the function
> is a method or internal function, argument 0 refers to implicit 'this'
> parameter. These annotations are used to validate/invalidate ref
> return functions that call such a ref return function. These
> annotations are also written in the automatically generated di
> interface files.
>
> See the DIP38 for more details and examples.

Link: http://wiki.dlang.org/DIP38

In order for this to work, the compiler must mangle according to ref specification.  Otherwise, a incorrectly synchronized .di file might link code that should otherwise be rejected.

I think this DIP might be too complex for acceptance.

My opinion is we should try the runtime check thing.  I think there will be very few cases where it is triggered.

-Steve

On 5/6/13 2:52 PM, Timothee Cour wrote:
> Abstract
>
> In short, the compiler internally annotates ref-return functions with
> ref(i1,...,iN) indicating that the function may return argument j
> (j=i1...iN) by reference (possibly via field accesses), where j is
> also a ref input argument. This list can be empty, and if the function
> is a method or internal function, argument 0 refers to implicit 'this'
> parameter. These annotations are used to validate/invalidate ref
> return functions that call such a ref return function. These
> annotations are also written in the automatically generated di
> interface files.
>
> See the DIP38 for more details and examples.

Knee-jerk reaction: this or any scheme based on internal (non-explicit) annotation for functions without that triggering inter-procedural analysis. The signature of a function should be everything the compiler can use as a basis in analysis.

Andrei

On 5/6/13 3:03 PM, Andrei Alexandrescu wrote:
> On 5/6/13 2:52 PM, Timothee Cour wrote:
>> Abstract
>>
>> In short, the compiler internally annotates ref-return functions with
>> ref(i1,...,iN) indicating that the function may return argument j
>> (j=i1...iN) by reference (possibly via field accesses), where j is
>> also a ref input argument. This list can be empty, and if the function
>> is a method or internal function, argument 0 refers to implicit 'this'
>> parameter. These annotations are used to validate/invalidate ref
>> return functions that call such a ref return function. These
>> annotations are also written in the automatically generated di
>> interface files.
>>
>> See the DIP38 for more details and examples.
>
> Knee-jerk reaction: this or any scheme based on internal (non-explicit)
> annotation for functions without that triggering inter-procedural
> analysis.

Awfully put. I meant: this or any scheme based on internal (non-explicit) annotation for functions cannot work without triggering inter-procedural analysis. (I haven't read the DIP yet.)

Andrei

> Awfully put. I meant: this or any scheme based on internal (non-explicit)
> annotation for functions cannot work without triggering inter-procedural
> analysis. (I haven't read the DIP yet.)

The proposed scheme doesn't require any inter-procedural analysis.
Each function is summarized by a label indicating its ref
dependencies, and a label propagation algorithm is used to label each
function.
The only tricky case is the (arguably rare) case of mutually recursive
ref return functions (corresponding to loops in the graph), for which
we can fall back to the runtime check, but for which I also believe we
can have a simple compile time solution with a bit more care.

I have updated the algorithmic details in the DIP.

On 5/6/13 6:41 PM, Timothee Cour wrote:
>> Awfully put. I meant: this or any scheme based on internal (non-explicit)
>> annotation for functions cannot work without triggering inter-procedural
>> analysis. (I haven't read the DIP yet.)
>
> The proposed scheme doesn't require any inter-procedural analysis.
> Each function is summarized by a label indicating its ref
> dependencies, and a label propagation algorithm is used to label each
> function.

BAM! Interprocedural analysis. Doesn't matter what name you invent for it. It's weird - you think you're in good shape, walking down the street, and suddenly you're in interprocedural analysis zone.

Andrei

> BAM! Interprocedural analysis. Doesn't matter what name you invent for it. It's weird - you think you're in good shape, walking down the street, and suddenly you're in interprocedural analysis zone.

ok, call it interprocedural analysis, but what would be your arguments against it, assuming:

A) I can convince (with code) that the propagation algorithm is simple
to implement and has negligible compile time overhead

B) it is safer than proposed approach in release builds (because
unittests in debug builds might not catch all such bugs, for example
things like min(ref int x, ref int y) which might be correct in some
code paths but not all)

C) it is faster in debug builds because no runtime checks

On 5/6/2013 11:52 AM, Timothee Cour wrote:
> See the DIP38 for more details and examples.


Handy link: http://wiki.dlang.org/DIP38

On 5/6/2013 11:52 AM, Timothee Cour wrote:
> Abstract
>
> In short, the compiler internally annotates ref-return functions with
> ref(i1,...,iN) indicating that the function may return argument j
> (j=i1...iN) by reference (possibly via field accesses), where j is
> also a ref input argument. This list can be empty, and if the function
> is a method or internal function, argument 0 refers to implicit 'this'
> parameter. These annotations are used to validate/invalidate ref
> return functions that call such a ref return function. These
> annotations are also written in the automatically generated di
> interface files.
>
> See the DIP38 for more details and examples.


It requires interprocedural analysis. This is possible for the same functions (such as template functions) that can infer pure/nothrow/@safe, but it cannot be done for ordinary functions.

> It requires interprocedural analysis. This is possible for the same functions (such as template functions) that can infer pure/nothrow/@safe, but it cannot be done for ordinary functions.

Can you please provide me a simple example for which the algorithm proposed in the DIP38 will fail, and that does not involve cycles (as described in the DIP) ?