Bump version number to 1.89.0

[pietroalbini]

Part of the release process. This PR must not be rolled up.

Closes #129461.

r? @ghost

[pietroalbini]

@bors r+ rollup=never p=100

Putting a high priority for this as I'd love to do more release steps during the weekend, since next week a lot of the release team (me included!) will be at RustWeek.

[bors]

📌 Commit 767d64d has been approved by pietroalbini

It is now in the queue for this repository.

[jieyouxu]

Oh hey the time bomb exploded (#133245)

[jieyouxu]

@bors r- (time bomb for the time diagnostic hack)

[rustbot]

Some changes occurred in need_type_info.rs

cc @lcnr

[pietroalbini]

Fixed the time bomb.

@bors r+ p=100 rollup=never

[bors]

📌 Commit 7dae318 has been approved by pietroalbini

It is now in the queue for this repository.

[bors]

⌛ Testing commit 7dae318 with merge 9d891b4...

[bors]

⌛ Testing commit 7dae318 with merge a9d24f2...

[bors]

⌛ Testing commit 7dae318 with merge dcecb99...

[bors]

☀️ Test successful - checks-actions
Approved by: pietroalbini
Pushing dcecb99 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing da1e442 (parent) -> dcecb99 (this PR)

Test differences

Show 3 test diffs

Stage 1

• [ui] tests/ui/inference/detect-old-time-version-format_description-parse.rs: pass -> [missing] (J0)

Stage 2

• [run-make] tests/run-make/compressed-debuginfo-zstd: pass -> ignore (ignored if LLVM wasn't build with zstd for ELF section compression (we want LLVM/LLD to be built with zstd support)) (J1)
• [ui] tests/ui/inference/detect-old-time-version-format_description-parse.rs: pass -> [missing] (J2)

Job group index

• J0: x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3
• J1: x86_64-gnu-nopt
• J2: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-2, x86_64-gnu, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard dcecb99176edf2eec51613730937d21cdd5c8f6e --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-rust-for-linux: 2643.9s -> 4313.2s (63.1%)
2. dist-apple-various: 9408.9s -> 5431.7s (-42.3%)
3. mingw-check: 1289.9s -> 1821.3s (41.2%)
4. test-various: 4196.6s -> 5808.4s (38.4%)
5. armhf-gnu: 4436.5s -> 6040.2s (36.1%)
6. x86_64-gnu: 6344.5s -> 8514.3s (34.2%)
7. arm-android: 5323.0s -> 7079.0s (33.0%)
8. x86_64-gnu-stable: 6531.0s -> 8483.6s (29.9%)
9. x86_64-gnu-nopt: 5774.7s -> 7367.5s (27.6%)
10. x86_64-gnu-aux: 6064.5s -> 7670.8s (26.5%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (dcecb99): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)	1.1%	[1.1%, 1.1%]	1
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[1.1%, 1.1%]	1

Max RSS (memory usage)

Results (primary 0.2%, secondary 1.5%)

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)	0.8%	[0.4%, 2.1%]	9
Regressions ❌ (secondary)	3.3%	[1.1%, 5.6%]	2
Improvements ✅ (primary)	-1.4%	[-2.9%, -0.6%]	4
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	0.2%	[-2.9%, 2.1%]	13

Cycles

Results (primary 0.6%)

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)	0.6%	[0.4%, 0.8%]	10
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[0.4%, 0.8%]	10

Binary size

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

Bootstrap: 771.723s -> 773.559s (0.24%)
Artifact size: 365.67 MiB -> 365.71 MiB (0.01%)