use clippy_config::Conf;

use clippy_config::types::{DisallowedPathWithoutReplacement, create_disallowed_map};

use clippy_utils::diagnostics::span_lint_and_then;

use clippy_utils::{match_def_path, paths};

use rustc_hir as hir;

use rustc_hir::def_id::{DefId, DefIdMap};

use rustc_lint::{LateContext, LateLintPass};

use rustc_middle::mir::CoroutineLayout;

use rustc_middle::ty::TyCtxt;

use rustc_session::impl_lint_pass;

use rustc_span::{Span, sym};

declare_clippy_lint! {

/// ### What it does

/// Checks for calls to `await` while holding a non-async-aware

/// `MutexGuard`.

///

/// ### Why is this bad?

/// The Mutex types found in [`std::sync`](https://doc.rust-lang.org/stable/std/sync/) and

/// [`parking_lot`](https://docs.rs/parking_lot/latest/parking_lot/) are

/// not designed to operate in an async context across await points.

///

/// There are two potential solutions. One is to use an async-aware `Mutex`

/// type. Many asynchronous foundation crates provide such a `Mutex` type.

/// The other solution is to ensure the mutex is unlocked before calling

/// `await`, either by introducing a scope or an explicit call to

/// [`Drop::drop`](https://doc.rust-lang.org/std/ops/trait.Drop.html).

///

/// ### Known problems

/// Will report false positive for explicitly dropped guards

/// ([#6446](https://github.com/rust-lang/rust-clippy/issues/6446)). A

/// workaround for this is to wrap the `.lock()` call in a block instead of

/// explicitly dropping the guard.

///

/// ### Example

/// ```no_run

/// # use std::sync::Mutex;

/// # async fn baz() {}

/// async fn foo(x: &Mutex<u32>) {

/// let mut guard = x.lock().unwrap();

/// *guard += 1;

/// baz().await;

/// }

///

/// async fn bar(x: &Mutex<u32>) {

/// let mut guard = x.lock().unwrap();

/// *guard += 1;

/// drop(guard); // explicit drop

/// baz().await;

/// }

/// ```

///

/// Use instead:

/// ```no_run

/// # use std::sync::Mutex;

/// # async fn baz() {}

/// async fn foo(x: &Mutex<u32>) {

/// {

/// let mut guard = x.lock().unwrap();

/// *guard += 1;

/// }

/// baz().await;

/// }

///

/// async fn bar(x: &Mutex<u32>) {

/// {

/// let mut guard = x.lock().unwrap();

/// *guard += 1;

/// } // guard dropped here at end of scope

/// baz().await;

/// }

/// ```

#[clippy::version = "1.45.0"]

pub AWAIT_HOLDING_LOCK,

suspicious,

"inside an async function, holding a `MutexGuard` while calling `await`"

}

declare_clippy_lint! {

/// ### What it does

/// Checks for calls to `await` while holding a `RefCell`, `Ref`, or `RefMut`.

///

/// ### Why is this bad?

/// `RefCell` refs only check for exclusive mutable access

/// at runtime. Holding a `RefCell` ref across an await suspension point

/// risks panics from a mutable ref shared while other refs are outstanding.

///

/// ### Known problems

/// Will report false positive for explicitly dropped refs

/// ([#6353](https://github.com/rust-lang/rust-clippy/issues/6353)). A workaround for this is

/// to wrap the `.borrow[_mut]()` call in a block instead of explicitly dropping the ref.

///

/// ### Example

/// ```no_run

/// # use std::cell::RefCell;

/// # async fn baz() {}

/// async fn foo(x: &RefCell<u32>) {

/// let mut y = x.borrow_mut();

/// *y += 1;

/// baz().await;

/// }

///

/// async fn bar(x: &RefCell<u32>) {

/// let mut y = x.borrow_mut();

/// *y += 1;

/// drop(y); // explicit drop

/// baz().await;

/// }

/// ```

///

/// Use instead:

/// ```no_run

/// # use std::cell::RefCell;

/// # async fn baz() {}

/// async fn foo(x: &RefCell<u32>) {

/// {

/// let mut y = x.borrow_mut();

/// *y += 1;

/// }

/// baz().await;

/// }

///

/// async fn bar(x: &RefCell<u32>) {

/// {

/// let mut y = x.borrow_mut();

/// *y += 1;

/// } // y dropped here at end of scope

/// baz().await;

/// }

/// ```

#[clippy::version = "1.49.0"]

pub AWAIT_HOLDING_REFCELL_REF,

suspicious,

"inside an async function, holding a `RefCell` ref while calling `await`"

}

declare_clippy_lint! {

/// ### What it does

/// Allows users to configure types which should not be held across await

/// suspension points.

///

/// ### Why is this bad?

/// There are some types which are perfectly safe to use concurrently from

/// a memory access perspective, but that will cause bugs at runtime if

/// they are held in such a way.

///

/// ### Example

///

/// ```toml

/// await-holding-invalid-types = [

/// # You can specify a type name

/// "CustomLockType",

/// # You can (optionally) specify a reason

/// { path = "OtherCustomLockType", reason = "Relies on a thread local" }

/// ]

/// ```

///

/// ```no_run

/// # async fn baz() {}

/// struct CustomLockType;

/// struct OtherCustomLockType;

/// async fn foo() {

/// let _x = CustomLockType;

/// let _y = OtherCustomLockType;

/// baz().await; // Lint violation

/// }

/// ```

#[clippy::version = "1.62.0"]

pub AWAIT_HOLDING_INVALID_TYPE,

suspicious,

"holding a type across an await point which is not allowed to be held as per the configuration"

}

impl_lint_pass!(AwaitHolding => [AWAIT_HOLDING_LOCK, AWAIT_HOLDING_REFCELL_REF, AWAIT_HOLDING_INVALID_TYPE]);

pub struct AwaitHolding {

def_ids: DefIdMap<(&'static str, &'static DisallowedPathWithoutReplacement)>,

}

impl AwaitHolding {

}

impl<'tcx> LateLintPass<'tcx> for AwaitHolding {

}

impl AwaitHolding {

}

fn emit_invalid_type(

}

fn is_mutex_guard(cx: &LateContext<'_>, def_id: DefId) -> bool {

}

fn is_refcell_ref(cx: &LateContext<'_>, def_id: DefId) -> bool {

}