+use clippy_utils::diagnostics::span_lint_and_sugg;
+use clippy_utils::in_macro;
+use clippy_utils::source::snippet;
+use if_chain::if_chain;
use rustc_data_structures::fx::FxHashMap;
use rustc_errors::Applicability;
use rustc_hir::{self as hir, ExprKind};
use rustc_session::{declare_lint_pass, declare_tool_lint};
use rustc_span::symbol::Symbol;
-use if_chain::if_chain;
-
-use crate::utils::{snippet, span_lint_and_sugg};
-
declare_clippy_lint! {
- /// **What it does:** Checks for struct constructors where the order of the field init
- /// shorthand in the constructor is inconsistent with the order in the struct definition.
+ /// **What it does:** Checks for struct constructors where all fields are shorthand and
+ /// the order of the field init shorthand in the constructor is inconsistent
+ /// with the order in the struct definition.
///
/// **Why is this bad?** Since the order of fields in a constructor doesn't affect the
/// resulted instance as the below example indicates,
/// let x = 1;
/// let y = 2;
///
- /// // This assertion never fails.
+ /// // This assertion never fails:
/// assert_eq!(Foo { x, y }, Foo { y, x });
/// ```
///
- /// inconsistent order means nothing and just decreases readability and consistency.
+ /// inconsistent order can be confusing and decreases readability and consistency.
///
/// **Known problems:** None.
///
/// }
/// let x = 1;
/// let y = 2;
+ ///
/// Foo { y, x };
/// ```
///
impl LateLintPass<'_> for InconsistentStructConstructor {
fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx hir::Expr<'_>) {
if_chain! {
+ if !in_macro(expr.span);
if let ExprKind::Struct(qpath, fields, base) = expr.kind;
let ty = cx.typeck_results().expr_ty(expr);
if let Some(adt_def) = ty.ty_adt_def();
cx,
INCONSISTENT_STRUCT_CONSTRUCTOR,
expr.span,
- "inconsistent struct constructor",
+ "struct constructor field order is inconsistent with struct definition field order",
"try",
sugg,
Applicability::MachineApplicable,