Range::step_by(0)

[llogiq]

This currently doesn't even panic, but happily loops forever. Well, unless it is clipped with .take(_) or some such.

[Manishearth]

We should probably have a single file which handles all lints which ban a type, function, or method

[llogiq]

Yeah, this should probably be in the same LintPass as #96.

[Manishearth]

Actually, no, #96 is a pure AST match, whereas all of these (Option::unwrap, Range::step_by(0)) are middle-based checks that need to use expr_ty and match_def_path

[llogiq]

Most ranges will be defined in the same line of code as their .step_by(..), so even if we don't use middle and just match either ExprMethodCall{step_by, [ExprRange{Lit(from), Lit(to)}, ref step]} or just ExprRange{..} without step_by (simplified here), we can probably catch a good percentage of occurrences.

We would need const folding for the check anyway (because the type won't tell us the range boundaries), so expr_ty would give us no benefit whatsoever.

[Manishearth]

No, I meant that all of these "ban a method" etc use expr_ty and match_def_path in a uniform way, which we can do all at once in a single place. (That's how I'm proposing this be organized, at least, feel free to propose something else 😄 )

[llogiq]

I agree wholeheartedly with your organization, but I think you've misclassified this issue. As I said, this should be a pure AST match + const folding.

[Manishearth]

Oh, you intend for this lint to only work on range literals?

Works for me!

[Manishearth]

Note: Using T-AST for lints which need const folding but are otherwise pure AST