Do not deny warnings in "fast" try builds

[Kobzol]

When we do the classic @bors try build without specifying try-job in the PR description, we want to get a compiler toolchain for perf./crater/local experimentation as fast as possible. We don't run any tests in that case, so it seems reasonable to also ignore warnings.

Fixes: #140753

r? @jieyouxu

try-job: dist-x86_64-linux

[Kobzol]

@bors try

(This should not fail)

[bors]

⌛ Trying commit 578b722 with merge c7de77a...

[bors]

💔 Test failed - checks-actions

[Kobzol]

@bors try

[bors]

⌛ Trying commit 09d13a0 with merge f5ff1f5...

[bors]

💔 Test failed - checks-actions

[Kobzol]

@bors try

[bors]

⌛ Trying commit ed792d4 with merge b5dfe06...

[bors]

☀️ Try build successful - checks-actions
Build commit: b5dfe06 (b5dfe06adec5b0a18372013b227c1a08bba96cb5)

[Kobzol]

Ok, the try build succeeded even with an unused variable. Now trying a full try build, which should fail.

@bors try

[Kobzol]

Good, seems to work fine, on a full try build warnings are still denied.

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in src/tools/opt-dist

cc @Kobzol

[Kobzol]

@rustbot ready

[jieyouxu]

Looks good. Can you also document this "specialness" of default try job in the rustc-dev-guide? I imagine someone will definitely run into this some day and become very confused :D

r=me otherwise

[jieyouxu]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @jieyouxu, @Kobzol

[Kobzol]

Good point, added a mention there. Let me know if you find it OK.

[jieyouxu]

I think this is worth trying, and wording looks good. Thanks!

[jieyouxu]

@bors r+ rollup

[bors]

📌 Commit 4f9bb8c has been approved by jieyouxu

It is now in the queue for this repository.

[jieyouxu]

Actually, since this modifies CI itself
@bors rollup=never (abundance of caution)

[bors]

⌛ Testing commit 4f9bb8c with merge 50aa041...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing 50aa041 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 fe348cd (parent) -> 50aa041 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 50aa04180709189a03dde5fd1c05751b2625ed37 --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-apple-2: 5064.9s -> 4299.7s (-15.1%)
2. dist-aarch64-apple: 5799.6s -> 5274.9s (-9.0%)
3. x86_64-gnu-distcheck: 4770.7s -> 4362.8s (-8.6%)
4. x86_64-apple-1: 7341.1s -> 7902.4s (7.6%)
5. dist-x86_64-apple: 9361.0s -> 10067.5s (7.5%)
6. dist-apple-various: 5335.9s -> 5720.6s (7.2%)
7. dist-arm-linux: 5070.2s -> 4761.2s (-6.1%)
8. dist-x86_64-mingw: 7669.6s -> 8086.1s (5.4%)
9. dist-powerpc64-linux: 5440.2s -> 5728.7s (5.3%)
10. x86_64-gnu-stable: 6619.6s -> 6958.0s (5.1%)

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 (50aa041): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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.7%	[0.5%, 0.7%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 0.6%, secondary -3.1%)

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%	[0.4%, 3.1%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.8%	[-1.8%, -0.5%]	4
Improvements ✅ (secondary)	-3.1%	[-5.7%, -1.1%]	7
All ❌✅ (primary)	0.6%	[-1.8%, 3.1%]	9

Cycles

Results (primary -0.3%, secondary 2.8%)

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.7%	[0.7%, 0.8%]	4
Regressions ❌ (secondary)	2.8%	[2.7%, 2.9%]	2
Improvements ✅ (primary)	-0.6%	[-2.3%, -0.4%]	15
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.3%	[-2.3%, 0.8%]	19

Binary size

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

Bootstrap: 771.734s -> 772.168s (0.06%)
Artifact size: 365.39 MiB -> 365.28 MiB (-0.03%)