Use ZST for fmt unsafety

[camsteffen]

as suggested here - #83302 (comment).

[rust-highfive]

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

[rust-highfive]

r? @scottmcm

(rust-highfive has picked a reviewer for you, use r? to override)

[camsteffen]

r? @Mark-Simulacrum

[camsteffen]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit dbfddbabc542aa6700738dc908423dfa924589b9 with merge f6eea4b87f48729f8ba6d9bc07003e4763f92b75...

[bors]

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

[rust-timer]

Queued f6eea4b87f48729f8ba6d9bc07003e4763f92b75 with parent e7958d3, future comparison URL.

[rust-timer]

Finished benchmarking commit (f6eea4b87f48729f8ba6d9bc07003e4763f92b75): comparison url.

Summary: This change led to moderate relevant improvements 🎉 in compiler performance.

• Moderate improvement in instruction counts (up to -1.5% on full builds of cranelift-codegen)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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

[Mark-Simulacrum]

r=me with an expanded comment on the UnsafeArg constructor. I think we should basically say something like "must be used for at most one call to new_v1_formatted, and created only if the other arguments meet the preconditions", with ideally those preconditions documented somewhere but for now we can just put in a FIXME for that.

[camsteffen]

@bors r=Mark-Simulacrum

[bors]

📌 Commit 09b37d7 has been approved by Mark-Simulacrum

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

  IMAGE: x86_64-gnu-tools
##[endgroup]
From https://github.com/rust-lang/rust
 * branch              master     -> FETCH_HEAD
Searching for toolstate changes between cfff31bc833070a00578bd6178160aeed56f28ba and 6ebf85007fc8e7fb4581c7f2fb201a6aaae6d937
Clippy or rustfmt subtrees were updated
##[group]Run src/ci/scripts/verify-channel.sh
src/ci/scripts/verify-channel.sh
shell: /bin/bash --noprofile --norc -e -o pipefail {0}
env:
---
......... (40/42)
..         (42/42)


An exception occured: Failed to launch the browser process!
Inconsistency detected by ld.so: dl-tls.c: 493: _dl_allocate_tls_init: Assertion `listp->slotinfo[cnt].gen <= GL(dl_tls_generation)' failed!


TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/master/docs/troubleshooting.md
== STACKTRACE ==
Error
Error
    at innerRunTestCode (/node-v14.4.0-linux-x64/lib/node_modules/browser-ui-test/src/index.js:442:16)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)


command did not execute successfully: "/node-v14.4.0-linux-x64/bin/node" "/checkout/src/tools/rustdoc-gui/tester.js" "--jobs" "16" "--doc-folder" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc" "--tests-folder" "/checkout/src/test/rustdoc-gui"


Build completed unsuccessfully in 0:00:15

[bors]

⌛ Testing commit 2efa9d7 with merge 67365d6...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 67365d6 to master...

[rust-timer]

Finished benchmarking commit (67365d6): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

• Large improvement in instruction counts (up to -1.6% on full builds of cranelift-codegen)
• Moderate regression in instruction counts (up to 0.7% on full builds of ctfe-stress-4)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[Mark-Simulacrum]

Regressions in deeply-nested-async appear to be due to extra instructions in the type privacy visitor, presumably caused by the println! expanding to include an additional type after this PR. That then creates extra work for the visitor.

Regressions in ctfe-stress have no such obvious cause, and the test doesn't actually contain any println!s. The self-profile view shows this as increasing the number of specializes queries, which is somewhat surprising; it looks like all specializes queries on this benchmark are coming from typeck > evaluation_obligation > specializes based on self-profile results.

My best guess is that the code here is the cause of the regression: presumably, we're trying to eliminate a newly added impl when checking some ImplCandidate. I compiled locally with before/after and -Zself-profile-events=all to get the inputs to both queries which produces some pretty weird results.

For the record, this was done with rust-lang/rustc-perf#1031 and then using:

./target/release/collector diff_local self-profile +30278d3cf92b581550933546370443a5d5700002 +67365d64bcdfeae1334bf2ff49587c27d1c973f0 --include ctfe-stress-4 --builds Check --runs Full
mmview ./results/Zsp-30278d3cf92b581550933546370443a5d5700002-ctfe-stress-4-Check-Full/Zsp.mm_profdata | rg 'label: specializes' -A1 | rg additional_data > before
mmview ./results/Zsp-67365d64bcdfeae1334bf2ff49587c27d1c973f0-ctfe-stress-4-Check-Full/Zsp.mm_profdata | rg 'label: specializes' -A1 | rg additional_data > after
diff -u <(sort ./base) <(sort ./after) > query.diff

I put up the diff here, but it shows some pretty weird inconsistencies that I wouldn't have expected from this PR -- my expectation would be that the specializes() query here is invoked deterministically, but that doesn't seem to be the case, or these indices are off. That said, all the changes in invocation are from core::ops::bit, which is not changed by this PR (right?) -- not even impls should be getting added in there.

There's some discussion on this particular topic on Zulip - https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/defpath.20printing

[Mark-Simulacrum]

Zulip discussion indicates that the shifts in indices are not unexpected. I still don't have a good explanation for why there's extra queries though -- that seems like it shouldn't happen for the changes in this PR, perhaps suggesting that trait resolution is somehow being affected here :/

[Mark-Simulacrum]

Okay, upon rebuilding before/after locally with debug logging enabled and some investigation, I'm pretty sure that the delta in query counts here was due to this landing before #89016 which fixed some "noise" in the iteration order here. That PR also reduces the amount of specializes queries (though it's not expected that this has any direct relationship to this PR); we are just seeing that there is now a hopefully more stable order.

Regardless, this source of noise is now understood and we can mark this regression as triaged; we don't expect any fixes to the ctfe-stress to be possible. The previous comment already triaged the await-call-tree regression as something we're also not expecting to fix and consider acceptable.

@rustbot label +perf-regression-triaged

(cc @lcnr in case you wanted some additional evidence for why that was important...)