mirror of
https://github.com/rust-lang/rust-clippy
synced 2024-12-20 10:03:37 +00:00
5fa961b951
Specifically, change `Ty` from this: ``` pub type Ty<'tcx> = &'tcx TyS<'tcx>; ``` to this ``` pub struct Ty<'tcx>(Interned<'tcx, TyS<'tcx>>); ``` There are two benefits to this. - It's now a first class type, so we can define methods on it. This means we can move a lot of methods away from `TyS`, leaving `TyS` as a barely-used type, which is appropriate given that it's not meant to be used directly. - The uniqueness requirement is now explicit, via the `Interned` type. E.g. the pointer-based `Eq` and `Hash` comes from `Interned`, rather than via `TyS`, which wasn't obvious at all. Much of this commit is boring churn. The interesting changes are in these files: - compiler/rustc_middle/src/arena.rs - compiler/rustc_middle/src/mir/visit.rs - compiler/rustc_middle/src/ty/context.rs - compiler/rustc_middle/src/ty/mod.rs Specifically: - Most mentions of `TyS` are removed. It's very much a dumb struct now; `Ty` has all the smarts. - `TyS` now has `crate` visibility instead of `pub`. - `TyS::make_for_test` is removed in favour of the static `BOOL_TY`, which just works better with the new structure. - The `Eq`/`Ord`/`Hash` impls are removed from `TyS`. `Interned`s impls of `Eq`/`Hash` now suffice. `Ord` is now partly on `Interned` (pointer-based, for the `Equal` case) and partly on `TyS` (contents-based, for the other cases). - There are many tedious sigil adjustments, i.e. adding or removing `*` or `&`. They seem to be unavoidable.
150 lines
5.1 KiB
Rust
150 lines
5.1 KiB
Rust
use clippy_utils::consts::{constant, Constant};
|
|
use clippy_utils::diagnostics::span_lint_and_then;
|
|
use clippy_utils::sext;
|
|
use if_chain::if_chain;
|
|
use rustc_hir::{BinOpKind, Expr, ExprKind};
|
|
use rustc_lint::{LateContext, LateLintPass};
|
|
use rustc_middle::ty::{self, Ty};
|
|
use rustc_session::{declare_lint_pass, declare_tool_lint};
|
|
use std::fmt::Display;
|
|
|
|
declare_clippy_lint! {
|
|
/// ### What it does
|
|
/// Checks for modulo arithmetic.
|
|
///
|
|
/// ### Why is this bad?
|
|
/// The results of modulo (%) operation might differ
|
|
/// depending on the language, when negative numbers are involved.
|
|
/// If you interop with different languages it might be beneficial
|
|
/// to double check all places that use modulo arithmetic.
|
|
///
|
|
/// For example, in Rust `17 % -3 = 2`, but in Python `17 % -3 = -1`.
|
|
///
|
|
/// ### Example
|
|
/// ```rust
|
|
/// let x = -17 % 3;
|
|
/// ```
|
|
#[clippy::version = "1.42.0"]
|
|
pub MODULO_ARITHMETIC,
|
|
restriction,
|
|
"any modulo arithmetic statement"
|
|
}
|
|
|
|
declare_lint_pass!(ModuloArithmetic => [MODULO_ARITHMETIC]);
|
|
|
|
struct OperandInfo {
|
|
string_representation: Option<String>,
|
|
is_negative: bool,
|
|
is_integral: bool,
|
|
}
|
|
|
|
fn analyze_operand(operand: &Expr<'_>, cx: &LateContext<'_>, expr: &Expr<'_>) -> Option<OperandInfo> {
|
|
match constant(cx, cx.typeck_results(), operand) {
|
|
Some((Constant::Int(v), _)) => match *cx.typeck_results().expr_ty(expr).kind() {
|
|
ty::Int(ity) => {
|
|
let value = sext(cx.tcx, v, ity);
|
|
return Some(OperandInfo {
|
|
string_representation: Some(value.to_string()),
|
|
is_negative: value < 0,
|
|
is_integral: true,
|
|
});
|
|
},
|
|
ty::Uint(_) => {
|
|
return Some(OperandInfo {
|
|
string_representation: None,
|
|
is_negative: false,
|
|
is_integral: true,
|
|
});
|
|
},
|
|
_ => {},
|
|
},
|
|
Some((Constant::F32(f), _)) => {
|
|
return Some(floating_point_operand_info(&f));
|
|
},
|
|
Some((Constant::F64(f), _)) => {
|
|
return Some(floating_point_operand_info(&f));
|
|
},
|
|
_ => {},
|
|
}
|
|
None
|
|
}
|
|
|
|
fn floating_point_operand_info<T: Display + PartialOrd + From<f32>>(f: &T) -> OperandInfo {
|
|
OperandInfo {
|
|
string_representation: Some(format!("{:.3}", *f)),
|
|
is_negative: *f < 0.0.into(),
|
|
is_integral: false,
|
|
}
|
|
}
|
|
|
|
fn might_have_negative_value(t: Ty<'_>) -> bool {
|
|
t.is_signed() || t.is_floating_point()
|
|
}
|
|
|
|
fn check_const_operands<'tcx>(
|
|
cx: &LateContext<'tcx>,
|
|
expr: &'tcx Expr<'_>,
|
|
lhs_operand: &OperandInfo,
|
|
rhs_operand: &OperandInfo,
|
|
) {
|
|
if lhs_operand.is_negative ^ rhs_operand.is_negative {
|
|
span_lint_and_then(
|
|
cx,
|
|
MODULO_ARITHMETIC,
|
|
expr.span,
|
|
&format!(
|
|
"you are using modulo operator on constants with different signs: `{} % {}`",
|
|
lhs_operand.string_representation.as_ref().unwrap(),
|
|
rhs_operand.string_representation.as_ref().unwrap()
|
|
),
|
|
|diag| {
|
|
diag.note("double check for expected result especially when interoperating with different languages");
|
|
if lhs_operand.is_integral {
|
|
diag.note("or consider using `rem_euclid` or similar function");
|
|
}
|
|
},
|
|
);
|
|
}
|
|
}
|
|
|
|
fn check_non_const_operands<'tcx>(cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>, operand: &Expr<'_>) {
|
|
let operand_type = cx.typeck_results().expr_ty(operand);
|
|
if might_have_negative_value(operand_type) {
|
|
span_lint_and_then(
|
|
cx,
|
|
MODULO_ARITHMETIC,
|
|
expr.span,
|
|
"you are using modulo operator on types that might have different signs",
|
|
|diag| {
|
|
diag.note("double check for expected result especially when interoperating with different languages");
|
|
if operand_type.is_integral() {
|
|
diag.note("or consider using `rem_euclid` or similar function");
|
|
}
|
|
},
|
|
);
|
|
}
|
|
}
|
|
|
|
impl<'tcx> LateLintPass<'tcx> for ModuloArithmetic {
|
|
fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>) {
|
|
match &expr.kind {
|
|
ExprKind::Binary(op, lhs, rhs) | ExprKind::AssignOp(op, lhs, rhs) => {
|
|
if op.node == BinOpKind::Rem {
|
|
let lhs_operand = analyze_operand(lhs, cx, expr);
|
|
let rhs_operand = analyze_operand(rhs, cx, expr);
|
|
if_chain! {
|
|
if let Some(lhs_operand) = lhs_operand;
|
|
if let Some(rhs_operand) = rhs_operand;
|
|
then {
|
|
check_const_operands(cx, expr, &lhs_operand, &rhs_operand);
|
|
}
|
|
else {
|
|
check_non_const_operands(cx, expr, lhs);
|
|
}
|
|
}
|
|
};
|
|
},
|
|
_ => {},
|
|
}
|
|
}
|
|
}
|