macros: fix wrong error messages

[c0va23]

Motivation

The macros tokio::main and tokio::test return invalid error messages if the function being wrapped has no return value. This was because the semicolon from the last statement was missing.

Also, since version 0.1.54 (or earlier), clippy::semicolon_if_nothing_returned triggered false-negative when using the macros tokio::test and tokio::main on functions without a result type.

Fixes: rust-lang/rust-clippy#7438

Solution

We can copy the semicolon and the return keyword from the last
statement from the body of the wrapped function.

[c0va23]

I'm not sure that this problem should be solved on the tokio-macros' side, and not on the clippy side. And I'm not sure that this fix won't break some scenarios for using the tokio::test and tokio::mainmacros.

But this change made it possible to update 'tokio-macros' without disabling 'clippy::semicolon_if_nothing_returned' on my project.

I will try to add tests for this problem. For now, I want to open a discussion to understand on which side the problem should be solved (clippy or tokio).

[Darksonn]

Honestly, I would prefer if this was fixed on the clippy side.

[c0va23]

@taiki-e, i removed these todos, because maybe I fixed them. Correct me if I'm wrong.

[c0va23]

I found tests in which it was planned to make similar changes.

And I redid the PR. Instead of adding a semicolon if the function does not have a result type. I check whether the last expression in the function body had a semicolon, and if so, I check whether this expression was 'return'.

[Darksonn]

Since this improves some existing bad error messages, I'm more positive for accepting this version. Can you add some tests that look like this?

#[tokio::main]
async fn main() -> Result<(), ()> {
    return Ok(());
}

#[tokio::main]
async fn main() -> Result<(), ()> {
    loop {
    }
}

It's ok if they don't have great error messages.

[c0va23]

@Darksonn, I will add such tests and fix the fallen tests (locally I ran tests on the latest version of the changes and they passed, but they fell on CI).

I think that it will still be necessary to correct the description of the PR, so that it better reflects the reason for these changes.

[c0va23]

Since this improves some existing bad error messages, I'm more positive for accepting this version. Can you add some tests that look like this?

#[tokio::main]
async fn main() -> Result<(), ()> {
    return Ok(());
}

#[tokio::main]
async fn main() -> Result<(), ()> {
    loop {
    }
}

It's ok if they don't have great error messages.

@Darksonn, i add this tests and fix filed tests.

And i update subject and description for PR and commit message.

[Darksonn]

Ah, actually, I think the tests I wanted was more like this:

#[tokio::main]
async fn main() {
    return Ok(());
}

#[tokio::main]
async fn main() {
    loop {
        return Ok(());
    }
}

I wanted to see what the error messages were in these cases. Sorry about posting the wrong version.

[c0va23]

Ah, actually, I think the tests I wanted was more like this:

#[tokio::main]
async fn main() {
    return Ok(());
}

This test already exists

tokio/tests-build/tests/fail/macros_type_mismatch.rs

Lines 8 to 11 in 9990139

	#[tokio::main]
	async fn missing_return_type() {
	return Ok(());
	}

#[tokio::main]
async fn main() {
loop {
return Ok(());
}
}

I wanted to see what the error messages were in these cases. Sorry about posting the wrong version.

Second test

tokio/tests-build/tests/pass/macros_main_loop.rs

Lines 4 to 10 in 9990139

	async fn main() -> Result<(), ()> {
	loop {
	if !never() {
	return Ok(());
	}
	}
	}

. But it compilled successful, without error messages.

[Darksonn]

I'm not sure what I wanted with the tests then. I must have confused myself. The PR looks good as is.

[c0va23]

@Darksonn, thanks a lot for helping with this PR.