Taiki Endo

> * There also seem to be problems with the function signature handling. (generics, where clause, etc.) It looks like this will be handled well if None-delimited groups are handled...

[Several users are already using the self argument in tokio::main](https://grep.app/search?q=%23%5C%5Btokio%3A%3Amain%5C%5D%5Cn.%2Aself&regexp=true&filter[lang][0]=Rust), so I'm not going to accept/approve removing support for self argument.

IIRC, Arm containers are executed in AWS's EKS. And AWS added support for IPv6 [a few weeks ago](https://github.com/aws/containers-roadmap/issues/835#issuecomment-1006804864). So it will probably be available in Cirrus CI in the near...

hmm, it's still slow sometimes: - 45m https://github.com/tokio-rs/tokio/runs/4674059799?check_suite_focus=true - 48m https://github.com/tokio-rs/tokio/runs/4674237353?check_suite_focus=true all runs: https://github.com/tokio-rs/tokio/actions/workflows/stress-test.yml?query=branch%3Ataiki-e%2Fvalgrind

Oh, we should use --error-exitcode. https://valgrind.org/docs/manual/manual-core.html#manual-core.erropts > --error-exitcode= [default: 0] > > Specifies an alternative exit code to return if Valgrind reported any errors in the run. When set to...

Ah, it's indeed not easy to test it. I think we can test this by adding the #4347's code to [tests-integration/src/bin](https://github.com/tokio-rs/tokio/tree/78e0f0b42a4f7a50f3986f576703e5a3cb473b79/tests-integration/src/bin) and doing something similar to the following shell script....

I guess the SB violation is due to futures 0.1's `UnsafeNotify::drop_raw`. https://github.com/rust-lang/futures-rs/blob/47b876fb67cf91833d04ed07720b82fc599fac93/src/task_impl/mod.rs#L551-L561 https://github.com/rust-lang/futures-rs/blob/47b876fb67cf91833d04ed07720b82fc599fac93/src/task_impl/mod.rs#L584-L607 https://github.com/rust-lang/futures-rs/blob/47b876fb67cf91833d04ed07720b82fc599fac93/src/task_impl/std/mod.rs#L642-L657

I think it's a good idea to add something like a map. In particular, there is currently no way to remove a specific future from the FuturesUnordered.

> The latter would probably be much easier. Yeah. I would prefer the latter.

Seems reasonable to me.