Give integer literals a sign instead of relying on negation expressions

[oli-obk]

A lot of situations in the compiler check for unary negation of literals, which I want to replace entirely at some point. I think the only place that should have to handle such things is the overflowing literals lint to detect double negation. Everywhere else we should just have the concept of negative literals

See also the corresponding MCP: rust-lang/compiler-team#835

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 25e4dd9 with merge 994d560...

[bors]

☀️ Try build successful - checks-actions
Build commit: 994d560 (994d560d7ca8e0cae1a0ed123e070dccfdf344a1)

[rust-timer]

Finished benchmarking commit (994d560): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.3%]	12
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.7%	[-1.4%, -0.3%]	17
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -0.7%, secondary -2.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.7%, 1.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.1%	[-3.1%, -3.1%]	1
Improvements ✅ (secondary)	-2.9%	[-6.7%, -2.0%]	12
All ❌✅ (primary)	-0.7%	[-3.1%, 1.7%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 785.339s -> 786.428s (0.14%)
Artifact size: 348.32 MiB -> 348.25 MiB (-0.02%)

[oli-obk]

This is actually a bugfix.

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @rust-lang/wg-const-eval

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

HIR ty lowering was modified

cc @fmease

Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

Some changes occurred in match checking

cc @Nadrieril

[oli-obk]

The 2 weeks of the MCP at rust-lang/compiler-team#835 is formally over

[bors]

☔ The latest upstream changes (presumably #137752) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

After reading the diff I think this a net negative even in case of HIR.

I understand that it is a follow up to the work on patterns in #134248 and its predecessors.
In case of patterns, this indeed makes sense, because the set of expressions in patterns is limited to some forms including negated literal expressions (*).

• (*) Not even literals, because -$expr is also supported, despite not being a literal, there are effectively parentheses there due to the macro variable.

I don't think the case of patterns should be extended to the rest of the language.
If some lints need to treat negated and non-negated literal expressions similarly, then maybe some helper methods will help, perhaps with flavors to differentiate between -10 and less literal-looking forms like -(10), -$lit or even - /* space */ 10.

Some type error treatment also becomes less natural with this approach, previously -"string" could be reported as an error just because strings do not implement Neg in general, not it requires a special case for literals.

As for the early compilation, I think the right mindset there is that negative literals simply don't exist, and if something looks like a negative literal to you, then it's just imagination. So I clearly disagree with the idea of "just having the concept of negative literals everywhere".
That applies to token streams, lexer, parser, and AST as well because AST is intertwined with the previous things pretty closely.
In this PR the rustc_ast* part of the diff looks mostly like an introduction of a great confusion into that model.