Match unmatched backticks in compiler/

[est31]

Found with GNU grep:

grep -rEn '^(([^`]*`){2})*[^`]*`[^`]*$' compiler/ | rg -v '\s*[//]?.{1,2}```'

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[est31]

These two I don't know what to put:

rust/compiler/rustc_hir_typeck/src/closure.rs

Line 401 in 13471d3

/// - S would be `fn(&u32) ->

rust/compiler/rustc_trait_selection/src/solve/assembly.rs

Line 250 in 13471d3

/// this case as projections as self types add `

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[saethlin]

I think you should split out the library diff into a separate PR, based on this topic: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Spelling.20is.20style.3F/near/328759605

[est31]

@saethlin I think the concerns were mostly about PRs, many of which very low effort, that were extremely huge and offloaded the reviewing of the tool to the PR reviewer. They had questionable quality, and sometimes it was questionable if they were improvements at all. Here the improvement is tiny, but very clear. It should be easy to review it. I just saw an error message with an unmatched when working on #108682, ` and then wondered about other occurrences of the character in the code.

This PR isn't just changing comments, it's also changing error messages of different kinds (both diagnostics and ICE messages).

[est31]

Okay reading through the thread of #58619, changes that only change rustc-internal comments aren't really liked, but if they are small in size, or easy to review they might still be accepted. Changes to public facing features/docs are still definitely wanted, even if cosmetic.

I've split up this PR into multiple commits:

• "Match end user facing unmatched backticks in compiler/" should be the least controversial. I see ICE messages, diagnostic messages, and lint documentation that gets rendered to the rustc mdbook (from my understanding, correct me if I'm wrong) as end user facing.
• "Match unmatched backticks in compiler/ that are part of rustdoc" concerns changes to the rustdoc that is rendered to the publicly available rustc-internal rustdoc. Those are rustc developer facing changes.
• "Match unmatched backticks in comments in compiler/" touches non-rustdoc comments only, that are only read by people who have directly opened the file (instead of browsing the rustdoc). This is probably the most controversial of the bunch.
• "Rustdoc-ify LiteralKind note" turns a // comment into a rustdoc comment, as well as adjusts an unmatched backtick to use ""s as is done in the surrounding rustdocs. Explicitly wanted.
• "Don't put integers into backticks during formatting" addresses @saethlin 's comments from above.

The commits have differing levels of controversialness. Please tell me which ones are not wanted and I should remove, and which ones I should put into different PRs. Thanks!

[est31]

Alright I have removed the commit that only changed the comments. I don't agree with the policy, and it might not actually be unwanted by that policy, but ultimately it's a choice I have to respect. Now all the changes should be non-controversial ones, I hope.

[Noratrieb]

You can make a separate PR with the compiler comments and add me or @WaffleLapkin as the reviewer, we're fine with reviewing it.

[est31]

Alright, I have removed even the rustdoc changes from this PR (outside of the one commit about LiteralKind) and moved the two into #108694. Sorry for all the noise, I hope now it should be easy enough to review the patches.

[petrochenkov]

Changes in this PR are certainly not in the same category (and amount) as in PRs that motivated #58619.
Missing left or right quotes a obviously typos/mistakes.
@bors r+

[bors]

📌 Commit c54f061 has been approved by petrochenkov

It is now in the queue for this repository.

[bors]

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.