rust/compiler/rustc_lint/src/async_fn_in_trait.rs
bors a48396984a Auto merge of #116688 - compiler-errors:rustfmt-up, r=WaffleLapkin,Nilstrieb
Format all the let-chains in compiler crates

Since rust-lang/rustfmt#5910 has landed, soon we will have support for formatting let-chains (as soon as rustfmt syncs and beta gets bumped).

This PR applies the changes [from master rustfmt to rust-lang/rust eagerly](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/out.20formatting.20of.20prs/near/374997516), so that the next beta bump does not have to deal with a 200+ file diff and can remain concerned with other things like `cfg(bootstrap)` -- #113637 was a pain to land, for example, because of let-else.

I will also add this commit to the ignore list after it has landed.

The commands that were run -- I'm not great at bash-foo, but this applies rustfmt to every compiler crate, and then reverts the two crates that should probably be formatted out-of-tree.
```
~/rustfmt $ ls -1d ~/rust/compiler/* | xargs -I@ cargo run --bin rustfmt -- `@/src/lib.rs` --config-path ~/rust --edition=2021 # format all of the compiler crates
~/rust $ git checkout HEAD -- compiler/rustc_codegen_{gcc,cranelift} # revert changes to cg-gcc and cg-clif
```

cc `@rust-lang/rustfmt`
r? `@WaffleLapkin` or `@Nilstrieb` who said they may be able to review this purely mechanical PR :>

cc `@Mark-Simulacrum` and `@petrochenkov,` who had some thoughts on the order of operations with big formatting changes in https://github.com/rust-lang/rust/pull/95262#issue-1178993801. I think the situation has changed since then, given that let-chains support exists on master rustfmt now, and I'm fairly confident that this formatting PR should land even if *bootstrap* rustfmt doesn't yet format let-chains in order to lessen the burden of the next beta bump.
2023-10-15 13:23:55 +00:00

129 lines
4.4 KiB
Rust

use crate::lints::AsyncFnInTraitDiag;
use crate::LateContext;
use crate::LateLintPass;
use rustc_hir as hir;
use rustc_trait_selection::traits::error_reporting::suggestions::suggest_desugaring_async_fn_to_impl_future_in_trait;
declare_lint! {
/// The `async_fn_in_trait` lint detects use of `async fn` in the
/// definition of a publicly-reachable trait.
///
/// ### Example
///
/// ```rust
/// pub trait Trait {
/// async fn method(&self);
/// }
/// # fn main() {}
/// ```
///
/// {{produces}}
///
/// ### Explanation
///
/// When `async fn` is used in a trait definition, the trait does not
/// promise that the opaque [`Future`] returned by the associated function
/// or method will implement any [auto traits] such as [`Send`]. This may
/// be surprising and may make the associated functions or methods on the
/// trait less useful than intended. On traits exposed publicly from a
/// crate, this may affect downstream crates whose authors cannot alter
/// the trait definition.
///
/// For example, this code is invalid:
///
/// ```rust,compile_fail
/// pub trait Trait {
/// async fn method(&self) {}
/// }
///
/// fn test<T: Trait>(x: T) {
/// fn spawn<T: Send>(_: T) {}
/// spawn(x.method()); // Not OK.
/// }
/// ```
///
/// This lint exists to warn authors of publicly-reachable traits that
/// they may want to consider desugaring the `async fn` to a normal `fn`
/// that returns an opaque `impl Future<..> + Send` type.
///
/// For example, instead of:
///
/// ```rust
/// pub trait Trait {
/// async fn method(&self) {}
/// }
/// ```
///
/// The author of the trait may want to write:
///
///
/// ```rust
/// # #![feature(return_position_impl_trait_in_trait)]
/// use core::future::Future;
/// pub trait Trait {
/// fn method(&self) -> impl Future<Output = ()> + Send { async {} }
/// }
/// ```
///
/// This still allows the use of `async fn` within impls of the trait.
/// However, it also means that the trait will never be compatible with
/// impls where the returned [`Future`] of the method does not implement
/// `Send`.
///
/// Conversely, if the trait is used only locally, if it is never used in
/// generic functions, or if it is only used in single-threaded contexts
/// that do not care whether the returned [`Future`] implements [`Send`],
/// then the lint may be suppressed.
///
/// [`Future`]: https://doc.rust-lang.org/core/future/trait.Future.html
/// [`Send`]: https://doc.rust-lang.org/core/marker/trait.Send.html
/// [auto traits]: https://doc.rust-lang.org/reference/special-types-and-traits.html#auto-traits
pub ASYNC_FN_IN_TRAIT,
Warn,
"use of `async fn` in definition of a publicly-reachable trait"
}
declare_lint_pass!(
/// Lint for use of `async fn` in the definition of a publicly-reachable
/// trait.
AsyncFnInTrait => [ASYNC_FN_IN_TRAIT]
);
impl<'tcx> LateLintPass<'tcx> for AsyncFnInTrait {
fn check_trait_item(&mut self, cx: &LateContext<'tcx>, item: &'tcx hir::TraitItem<'tcx>) {
if let hir::TraitItemKind::Fn(sig, body) = item.kind
&& let hir::IsAsync::Async(async_span) = sig.header.asyncness
{
// RTN can be used to bound `async fn` in traits in a better way than "always"
if cx.tcx.features().return_type_notation {
return;
}
// Only need to think about library implications of reachable traits
if !cx.tcx.effective_visibilities(()).is_reachable(item.owner_id.def_id) {
return;
}
let hir::FnRetTy::Return(hir::Ty { kind: hir::TyKind::OpaqueDef(def, ..), .. }) =
sig.decl.output
else {
// This should never happen, but let's not ICE.
return;
};
let sugg = suggest_desugaring_async_fn_to_impl_future_in_trait(
cx.tcx,
sig,
body,
def.owner_id.def_id,
" + Send",
);
cx.tcx.emit_spanned_lint(
ASYNC_FN_IN_TRAIT,
item.hir_id(),
async_span,
AsyncFnInTraitDiag { sugg },
);
}
}
}