Effective breakage to jiff due to ambiguous_negative_literals

[traviscross]

We should discuss this bit of evidence that came in after the FCP completed on:

• Implement lint against ambiguous negative literals #121364

@BurntSushi said:

This completely broke Jiff once the change landed. Because it specifically supports negating spans like -1.hour(). In the case of Jiff, there is no ambiguity because -1.hour() and (-1).hour() and -(1.hour()) are all precisely equivalent.

cc @BurntSushi @rust-lang/lang

@rustbot labels +T-lang +I-lang-nominated

[workingjubilee]

This lint indeed assumes the operations are ordering-sensitive. Like abs. Perhaps the lint should be on the function, not the operator?

[Urgau]

The partially-uplifted Clippy clippy::precedence lint (which made up this lint) had a basic heuristic for not linting in cases where the precedence of the operations didn't matter. It was part of the original PR, but @RalfJung preferred consistent linting [comment]:

Personally I'd prefer it to warn consistently, even if the semantics of the function mean it doesn't matter. (a) that seems more consistent and less surprising, and (b) I am writing tests which ensure that sin behaves correctly, and I care about which sign the argument actually has.

[Urgau]

If it's decided that it's not worth linting on these cases, I would propose using the #[diagnostic] namespace by introducing an opt-out, that library authors could use on to suppress the lint for downstream users. Something like #[diagnostic::irrelevant_negative_literal_precedence] (better name to be found) which could applied to all the relevant function definitions.

[traviscross]

We discussed this in our lang triage call today.

@Urgau: If you would, we'd like this lint changed to allow-by-default while we consider this question further.

cc @compiler-errors

[Urgau]

As asked the lint was changed to allow-by-default in #128449.