False positive in unnecessary_cast with hex literals

[glfmn]

clippy 0.0.212 (69f99e7 2019-12-14)

The lint for #[warn(unnecessary_cast)] acts strangely when integers are written in hex. Example:

let r = 0x1b as f32 / 255.0;
//      ^^^^^^^^^^^ - unnecessary cast write integer literal as 29_f32

However, f32 is valid hex, so if I write 0x1b_f32 rust interprets the value as an integer. It does helpfully output the integer literal as a decimal number in the suggestion, but it isn't hex anymore which defeats the purpose.

[mlegner]

I would like to work on this issue and investigated a bit. Unfortunately, the AST doesn't seem to record whether the integer literal was written in hex or decimal notation. The enum LitIntType only records the suffix of the literal.

It seems to me that properly resolving these false positives would require extending the LitKind::Int node with additional information in the main rust repository. Am I missing something?

[glfmn]

@mlegner that's unfortunate, I'm not really aware of those implementation details but from a glance it seems your summation of the problem is accurate.

[flip1995]

Clippy has it's own struct, that can be build from literals and from where you can detect if it is a hex, bin, or oct literal:

rust-clippy/clippy_lints/src/literal_representation.rs

Lines 132 to 150 in 0f4a3fe

	pub(super) struct NumericLiteral<'a> {
	/// Which radix the literal was represented in.
	radix: Radix,
	/// The radix prefix, if present.
	prefix: Option<&'a str>,
	/// The integer part of the number.
	integer: &'a str,
	/// The fraction part of the number.
	fraction: Option<&'a str>,
	/// The character used as exponent seperator (b'e' or b'E') and the exponent part.
	exponent: Option<(char, &'a str)>,
	/// The type suffix, including preceding underscore if present.
	suffix: Option<&'a str>,
	}
	impl<'a> NumericLiteral<'a> {
	fn from_lit(src: &'a str, lit: &Lit) -> Option<NumericLiteral<'a>> {

So no need to modify the rustc AST.

[mlegner]

Thanks a lot for the pointer, @flip1995. I was able to resolve this issue but had to modify some of the code you referenced. The changes are in the linked PR #5257.

[glfmn]

Thanks for addressing this so quickly!