do not 'return' in 'throw_' macros

[RalfJung]

In #69839 we turned a closure into a try block, but it turns out that does not work with our throw_ macros, which return so they skip the try.

Here we fix that. For some reason that means we also have to remove some ;.

r? @oli-obk

[oli-obk]

wtf... how does

fn foo() -> Result<String, ()> {
    Err(())?
}

compile?! I can only guess that it defaults the Ok type of the Result to !, there's no other explanation I can come up with. (Also Result::<String, ()>::Err(())? errors).

[oli-obk]

@bors r+

[bors]

📌 Commit a39875b has been approved by oli-obk

[RalfJung]

@bors r-
Waiting until tmr to make sure we get a nightly with Miri.

[tspiteri]

@oli-obk wrote:

how does [Err(())?] compile?!

Result::<Result<String, ()>, ()>::Err(())? works, so I'm guessing it infers that the unwrapped Ok variant would have the type of the return value.

[RalfJung]

@bors r=oli-obk

[bors]

📌 Commit a39875b has been approved by oli-obk

[goffrie]

Here we fix that. For some reason that means we also have to remove some ;.

If you change the macro to Err::<!, _>(...)? then the compiler will be able to see that it doesn't return.

[RalfJung]

@goffrie ah, that makes sense! I added that type annotation, and checked that then I could re-add the semicolons.

However, I kept the part that removes them here, matching (I think) the usual Rust policy for trailing expressions.

@bors r=oli-obk

[bors]

📌 Commit e46b3c2 has been approved by oli-obk