rust-clippy/clippy_lints/src/modulo_arithmetic.rs
Nicholas Nethercote 5fa961b951 Overhaul TyS and Ty.
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.
2022-02-15 16:03:24 +11:00

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);
}
}
};
},
_ => {},
}
}
}