chore: reduce dependency to pin-utils

[tisonkun]

This refers to #2924.

cc @taiki-e as for "it is reasonable to remove it in v0.4", IIUC I can open a follow-up PR to remove this macro and update the corresponding related usage, only we don't mark that PR as 0.3-backport?

BTW, if there is anything I can help in backporting, please let me know. In my experience, it means opening a PR against branch 0.3 and do the same change.

[taiki-e]

Thanks for the PR!

futures-util/src/future/future/mod.rs (which is a module for Future trait related things) is not the proper place to put this macro, so perhaps it is better to create futures-util/src/macros.rs and put it there.

[taiki-e]

This should refer $crate::__private::Pin instead of ::core::pin::Pin, as pin-utils does.

[tisonkun]

Any rationale here?

I'm afraid that, as futures_util::__private is guarded by async-await flag, it would create an extra flag gate to use this name.

[taiki-e]

Any rationale here?

See rust-lang/pin-utils#26 (comment).

I'm afraid that, as futures_util::__private is guarded by async-await flag, it would create an extra flag gate to use this name.

There is no problem with removing the cfg from __private module.
That cfg just indicates who the current user is, nothing special.

[tisonkun]

OK. Let me use $crate::__private and remove the cfg.

Maybe tomorrow to trigger CI with the new toolchain that fixes the current CI failure.

[tisonkun]

@taiki-e Thanks for your review! Comments addressed.

... except the one about $crate::__private::Pin that I found the __private mod is guarded by "async-await" flag and being a bit uncertain to use.

[tisonkun]

error: unused attribute `<cfg_attr>`
   --> futures-util/src/stream/stream/mod.rs:181:1
    |
181 | #[cfg_attr(target_os = "none", cfg(target_has_atomic = "ptr"))]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: the built-in attribute `<cfg_attr>` will be ignored, since it's applied to the macro invocation `delegate_all`
   --> futures-util/src/stream/stream/mod.rs:183:1
    |
183 | delegate_all!(
    | ^^^^^^^^^^^^
    = note: `-D unused-attributes` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(unused_attributes)]`

Doesn't seem related .. Unsure what happen.

[taiki-e]

error: unused attribute `<cfg_attr>`
   --> futures-util/src/stream/stream/mod.rs:181:1
    |
181 | #[cfg_attr(target_os = "none", cfg(target_has_atomic = "ptr"))]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: the built-in attribute `<cfg_attr>` will be ignored, since it's applied to the macro invocation `delegate_all`
   --> futures-util/src/stream/stream/mod.rs:183:1
    |
183 | delegate_all!(
    | ^^^^^^^^^^^^
    = note: `-D unused-attributes` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(unused_attributes)]`

Doesn't seem related .. Unsure what happen.

This is rust-lang/rust#138779.

[tisonkun]

@taiki-e Looks good now. Please give another review. And see my comment for the following step:

cc @taiki-e as for "it is reasonable to remove it in v0.4", IIUC I can open a follow-up PR to remove this macro and update the corresponding related usage, only we don't mark that PR as 0.3-backport?

BTW, if there is anything I can help in backporting, please let me know. In my experience, it means opening a PR against branch 0.3 and do the same change.

[tisonkun]

@taiki-e any comment on my following plan? I may create a new PR to remove pin_mut! macro and use the core lib macro instead.

That PR would not backport to 0.3 so that we really remove the dependency to pin-utils in 0.4.

[taiki-e]

I think the steps to remove pin_mut in v0.4 are:

1. Replace pin_mut with pin in docs (other than docs of pin_mut itself). This can be backported to v0.3.
2. Bump MSRV to 1.68 (for now only for v0.4).
3. Replace pin_mut uses in our code base.
4. Remove pin_mut.

(2 and 3 can be done at the same time, but it would be better to separate 1 and 4 due to backporting and potential reverting.)

[tisonkun]

Thanks for your guide @taiki-e! Let me try to handle it in the following days.

BTW, to implement #2901, we may end up with MSRV >= 1.85 in futures 0.4?

[taiki-e]

BTW, to implement #2901, we may end up with MSRV >= 1.85 in futures 0.4?

Yes. The next debian stable will use at least 1.85, so 1.85 would be an acceptable and reasonable.

[tisonkun]

Replace pin_mut with pin in docs (other than docs of pin_mut itself).

I'm trying to replace pin_mut with pin ..

@taiki-e But the macro core::pin::pin is only stabilized after 1.68. Do you mean that our docs (tests?) should be no_run now? Or I don't know how to search those no-code references. I may start with MSRV bump and then replace all the internal usage of pin_mut.

[taiki-e]

We don't run tests on MSRV, so tests and doc examples can use APIs that unavailable on MSRV.