Make borrowed-to-unsafe coercions introduce minimum region constraints

[nikomatsakis]

This is an idea that @alexcrichton and I had some time back but I think it was generally lost in the shuffle of things to do. The idea is that whenever a &T (resp. &mut T) is coerced to a *const T (resp. *const T or *mut T), we should treat that as a reborrow for the enclosing temporary scope. This would ensure that the borrow checker treats the &T (resp. &mut T) as borrowed for the enclosing temporary scope. This means that users can be sure that it is safe to use * pointer so long as it does not outlive the enclosing temporary scope. Longer than that the rules get trickier.

Some notes from IRC that pretty much say the same thing:

[01:27:21] <nmatsakis> aturon: huon: that reminds me, there was a (somewhat minor) change to region inference I wanted to make which would help a lot without avoiding (purely technical, I think)
                       violations of the safe aliasing rules
[01:27:45] <nmatsakis> right now if you do fn foo(x: *mut int) and you call it with foo(&mut something-or-other)
[01:27:59] <nmatsakis> region-inference treats that like "no constraint what-so-ever on the region of the &mut that is passed in",
[01:28:07] <nmatsakis> which means it will infer a region that ends before the call even begins,
[01:28:15] <nmatsakis> so you are technically in violation before you even enter `foo()`
[01:28:39] <nmatsakis> I wanted to modify the rules for coercion from &-to-* to introduce a constraint that the region at least outlives the innermost enclosing temp scope
[01:28:54] <nmatsakis> which means basically that when a & is coerced to a *, you know that * is useful about until the end of the statement
[01:28:59] <nmatsakis> safely usable that is
[01:29:23] <nmatsakis> I should open an issue about that I guess

cc #19733

[nikomatsakis]

Nominating for 1.0. This is strictly speaking a backwards incompat change in that some programs could start failing borrow checker but I wouldn't expect much impact.

[huonw]

What does this mean for code? fn foo(*mut, *mut), foo(&mut x, &mut x) becomes invalid?

[alexcrichton]

@huonw I believe that you could recover the old behavior with an explicit cast in that case, the reborrow, if I remember correctly, was only with automatic coercions.

For example:

fn foo(a: *mut int, b: *mut int) {}

foo(&mut x, &mut x); // error
foor(&mut x, &mut x as *mut int); // error
foor(&mut x as *mut int, &mut x); // ok

[Gankra]

This seems like a relatively benign change. Although perhaps very confusing the first time you run into it.

[brson]

Slightly backwwards incompat. could possibly be a post-1.0 bugfix

[pnkfelix]

cc me

[zwarich]

cc me

[steveklabnik]

So, it's far past 1.0. How are we feeling about this change? Is this the kind of back-incompat-change that's still worth it?

[glaebhoerl]

cc rust-lang/rfcs#1447

[nikomatsakis]

I think we can close this in favor of rust-lang/rfcs#1447. In any case, I've come to think that this particular change is not the right approach -- we ought to be making rules that are not based on the results of region inference in any way, since those are so unpredictable.