Avoid underflow for splatted rust-call receivers#158850
Conversation
rustbot
added
S-waiting-on-review
|
r? @jieyouxu rustbot has assigned @jieyouxu. Use Why was this reviewer chosen?The reviewer was selected based on:
|
There was a problem hiding this comment.
I think that banning splat on rust-call and closures in PR #158645 will make these fixes obsolete. But there's still some useful changes we can make in this code.
|
|
||
| impl<T> dyn FnOnce(T) -> () { | ||
| //~^ ERROR cannot define inherent `impl` for a type outside of the crate | ||
| extern "rust-call" fn call_once(#[splat] self) {} |
There was a problem hiding this comment.
Unfortunately splatted rust-call will be banned in PR #158645.
I think that's a good way forward, because:
- rust-call already de-tuples its arguments
- the semantics of splat in addition to rust-call are undefined, and there's no obvious way it should work
- if we ban it now, people can't rely on any incomplete feature behaviour
Later, if we decide on a sensible way for it to work, we can re-enable it with those semantics.
I would still like to merge this test, but with the error output from #158645.
| @@ -1717,14 +1717,18 @@ fn check_fn_or_method<'tcx>( | |||
| let has_implicit_self = hir_decl.implicit_self().has_implicit_self(); | |||
| let mut inputs = sig.inputs().iter().skip(if has_implicit_self { 1 } else { 0 }); | |||
| // FIXME(splat): support the rest of closure splatting, or replace this code with an error | |||
There was a problem hiding this comment.
Based on the ban in #158645, this splatted closure code should probably become a compiler error (or an ICE bug).
And we can delete the rest of the calculations, so there's no underflow.
|
Oh, and thank you for the PR! It's great to have a bunch of people finding bugs and fixing things. |
4 participants
Fixes #158800
We alreay have proper error for
#[splat] selfin following code, so here we just need to avoid the overflow.cc @teor2345