Restore broken code block highlighting

Author: senekor

content/Rust-1.26.1.md

@@ -104,12 +104,12 @@ context would return true, which is a bug; now, this comparison returns false.
 In some cases that may mean that the behavior of code will change, but we
 expect this to be relatively unlikely.
 
-```rust,ignore
+```rust
 use std::f64::NAN;
 const FOO: bool = ::std::f64::NAN >= ::std::f64::NAN;
-# On 1.26.0
+// On 1.26.0
 assert_eq!(FOO, true);
-# On 1.26.1
+// On 1.26.1
 assert_eq!(FOO, false);
 ```
 

content/Rust-1.30.0.md

@@ -153,7 +153,7 @@ is made stable, which gives you the needed APIs to write these sorts of macros.
 It also has significantly improved the APIs for errors, and crates like `syn` and
 `quote` are already using them. For example, before:
 
-```rust,ignore
+```rust
 #[derive(Serialize)]
 struct Demo {
     ok: String,
@@ -202,7 +202,7 @@ let json = serde_json::from_str("...");
 The trick here is that the 'old' style wasn't always needed, due to the way Rust's
 module system worked:
 
-```rust,ignore
+```rust
 extern crate serde_json;
 
 fn main() {

content/Rust-1.54.0.md

@@ -32,7 +32,7 @@ from the appropriate page on our website, and check out the
 Rust 1.54 supports invoking function-like macros inside attributes. Function-like macros can be either `macro_rules!` based or procedural macros which are invoked like `macro!(...)`. One notable use case for this is including documentation from other files into Rust doc comments. For example, if your project's README represents a good documentation comment, you can use `include_str!` to directly incorporate the contents. Previously, various workarounds allowed similar functionality, but from 1.54 this is much more ergonomic.
 
 
-```rust=
+```rust
 #![doc = include_str!("README.md")]
 ```
 

content/Rust-1.60.0.md

@@ -32,7 +32,7 @@ the beta channel (`rustup default beta`) or the nightly channel (`rustup default
 
 Support for LLVM-based coverage instrumentation has been stabilized in rustc. You can try this out on your code by rebuilding your code with `-Cinstrument-coverage`, for example like this:
 
-```shell=
+```sh
 RUSTFLAGS="-C instrument-coverage" cargo build
 ```
 
@@ -48,7 +48,7 @@ for report generation. `llvm-cov` combines the processed output, from
 `llvm-profdata`, and the binary itself, because the binary embeds a mapping from
 counters to actual source code regions.
 
-```shell=
+```sh
 rustup component add llvm-tools-preview
 $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata merge -sparse default.profraw -o default.profdata
 $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-cov show -Xdemangler=rustfilt target/debug/coverage-testing \
@@ -77,7 +77,7 @@ rustc binary used to compile your code.
 
 Cargo has stabilized support for collecting information on build with the `--timings` flag.
 
-```shell
+```sh
 $ cargo build --timings
    Compiling hello-world v0.1.0 (hello-world)
       Timing report saved to target/cargo-timings/cargo-timing-20220318T174818Z.html

content/const-eval-safety-rule-revision.md

@@ -276,7 +276,7 @@ If you can test compiling your crate atop the 1.64-beta before the stable
 release goes out on September 22nd, all the better! One easy way to try the beta
 is to use [rustup's override shortand][rustup] for it:
 
-```shell
+```sh
 $ rustup update beta
 $ cargo +beta build
 ```

content/inside-rust/polonius-update.md

@@ -17,7 +17,7 @@ Polonius refers to a few things. It is a [new formulation](http://smallcultfollo
 
 The motivating example for Polonius is the so-called ["Problem Case #3: conditional control flow across functions"](https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md#problem-case-3-conditional-control-flow-across-functions): here, returning a reference out of a function, from a conditional.
 
-```rust=
+```rust
 fn get_default<'r, K: Hash + Eq + Copy, V: Default>(
     map: &'r mut HashMap<K, V>,
     key: K,
@@ -37,7 +37,7 @@ Returning the mutable reference `value` in the `Some` path requires the mutable
 
 Fixing this borrowck issue requires more precision about flow-sensitivity. It also hints at limitations in our modeling of lifetimes, which appear more clearly in cases with only slightly more complicated control flow, like [issue #47680](https://github.com/rust-lang/rust/issues/47680):
 
-```rust=
+```rust
 struct Thing;
 
 impl Thing {

content/inside-rust/test-infra-oct-2024.md

@@ -86,7 +86,7 @@ so we can remove it as it was causing friction in adding new directives and
 authoring tests. For example, the [Specification Team][t-spec] wanted to add a
 `//@ reference` directive, but the legacy directive check would trigger on:
 
-```rust,no_run
+```rust
 // So what if we added a
 // reference to the           <- `reference` is a known directive, and
 //                               `// reference` looks suspcious!

content/inside-rust/this-development-cycle-in-cargo-1.79.md

@@ -227,7 +227,7 @@ We could add `cargo --release <script>`.
 This runs into a common challenge of `#!` processing being limited in processing of interpreter arguments which can't be resolved in a fully cross-platform way.
 
 Unfortunately, you can't just do:
-```toml=
+```toml
 [profile.dev]
 inherits = "release"
 ```

content/inside-rust/this-development-cycle-in-cargo-1.80.md

@@ -187,7 +187,7 @@ Discussion is still on-going.
 <!-- 2024-06-04 -->
 As far as we are aware, the last remaining step before stabilization is
 renaming the configuration ([#13540](https://github.com/rust-lang/cargo/issues/13540)):
-```toml=
+```toml
 [resolver]
 something-like-precedence = "something-like-rust-version"
 ```

content/inside-rust/this-development-cycle-in-cargo-1.82.md

@@ -178,7 +178,7 @@ For individual tests, one thing holding back the migration was how json comparis
 Cargo's programmatic API generally uses [jsonlines](https://jsonlines.org/) but that doesn't work so well for humans reading and editing the content.
 Switching to snapbox adds an extra complexity because it highlights a failure by diffing the expected and actual test results and
 diffing works best with line-oriented content.
-```jsonld=
+```json
 {"executable":"[ROOT]/foo/target/debug/007bar[EXE]","features":[],"filenames":"{...}","fresh":false,"manifest_path":"[ROOT]/foo/Cargo.toml","package_id":"path+[ROOTURL]/foo#0.0.1","profile":"{...}","reason":"compiler-artifact","target":"{...}"}
 {"reason":"build-finished","success":true}
 ```
@@ -205,15 +205,15 @@ It would run counter to snapbox's model to implicitly store data in a format con
 We solved this in [snapbox#348](https://github.com/assert-rs/snapbox/issues/348) by allow making it explicit, by allowing the the test author to declare the format of the expected data and what it will be compared to.
 
 This allowed us to replace
-```rust=
+```rust
         .with_stdout_data(str![[r#"
 {"executable":"[ROOT]/foo/target/debug/007bar[EXE]","features":[],"filenames":"{...}","fresh":false,"manifest_path":"[ROOT]/foo/Cargo.toml","package_id":"path+[ROOTURL]/foo#0.0.1","profile":"{...}","reason":"compiler-artifact","target":"{...}"}
 {"reason":"build-finished","success":true}
 
 "#]].json_lines())
 ```
 with
-```rust=
+```rust
         .with_stdout_data(
             str![[r#"
 [