[Issue 8845] Can't pass immediate or rvalue args to ref function parameters

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=8845


Zach the Mystic <reachzach at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reachzach at gmail.com


--- Comment #19 from Zach the Mystic <reachzach at gmail.com> 2013-11-27 11:12:32 PST ---
(In reply to comment #17)
> I was in the camp arguing for a 'scope ref' concept, which would rely on escape
> analysis to enforce that a 'scope ref' doesn't escape, but we were never going
> to win that argument.
> 
> The plan that Walter was most enthusiastic about was, if the function is passed
> an rvalue, generate an implicit temp in the caller's stack and pass it through.
> If the function being called returns a ref, it would add an implicit function
> exit condition which would validate that the ref being returned is not within
> the function's stack (controlled by -noboundscheck for optimisation).
> This way, it would be safe to return a ref that was passed in to a function,
> but not a function local. This would cascade outwards.

Related ref safety Issue 9537.

I don't think you need to win the 'scope ref' issue because the -noboundscheck
version will work fine. Then temporaries will be safe, so long as the called
functions don't save their addresses off of the stack somewhere.

To ensure safety, I think the compiler needs to keep track of some bits on its
parameters and expressions. Some ideas:

Each reference variable has a 'mayBeLocal' bit and a 'mayBeRefParam' bit. Each
function has a 'mayReturnRefParam' bit. All known references to locals have
'mayBeLocal' set, and all ref parameters have 'mayBeRefParam' set. Any attempt
to return a reference to a 'mayBeLocal' causes the appropriate error. Returning
a 'mayBeRefParam' reference causes the function to be marked
'mayReturnRefParam', and the result will be the safest of what was passed in.
Any time the compiler can't prove that a reference parameter will not be
returned, it marks the function as 'mayReturnRefParam' and requires the runtime
stack bounds check. Now ref returns are safe.

The above scheme is blunt. It will unnecessarily restrict a few cases where
more than one ref parameter is passed, but only one is returned:

ref T fun(ref T a, ref T b) {
  return a;
}

ref T gun(ref T a) {
  T b;
  return fun(a, b); // fails unnecessarily, because b is local
}

If there were a lot of such cases in practice, some addition to this simple
scheme may be necessary.

Other kinds of unsafe escapes would have to be handled in other ways (e.g. a
bit 'mayGetSavedOffStack' on parameters). But the main case of ref returns is
handled at least. Then rvalue refs would be safe.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------