Merge pull request #2446 from fmease/fix-warning-blocks

Fix some warning blocks that contain Markdown

Author: fmease

src/doc/rustc-dev-guide/src/autodiff/flags.md

@@ -16,7 +16,9 @@ LooseTypes // Risk incorrect derivatives instead of aborting when missing Type I
 ```
 
 <div class="warning">
+
 `LooseTypes` is often helpful to get rid of Enzyme errors stating `Can not deduce type of <X>` and to be able to run some code. But please keep in mind that this flag absolutely has the chance to cause incorrect gradients. Even worse, the gradients might be correct for certain input values, but not for others. So please create issues about such bugs and only use this flag temporarily while you wait for your bug to be fixed.
+
 </div>
 
 ### Benchmark flags

src/doc/rustc-dev-guide/src/tests/ci.md

@@ -186,9 +186,11 @@ Note that if you start the default try job using `@bors try`, it will skip build
 Multiple try builds can execute concurrently across different PRs.
 
 <div class="warning">
-bors identify try jobs by commit hash. This means that if you have two PRs
+
+Bors identifies try jobs by commit hash. This means that if you have two PRs
 containing the same (latest) commits, running `@bors try` will result in the
 *same* try job and it really confuses `bors`. Please refrain from doing so.
+
 </div>
 
 [rustc-perf]: https://github.com/rust-lang/rustc-perf

src/doc/rustc-dev-guide/src/tests/compiletest.md

@@ -438,7 +438,9 @@ To work around this when working on a particular test, temporarily create a
 with these contents:
 
 <div class="warning">
+
 Be careful not to add this `Cargo.toml` or its `Cargo.lock` to your actual PR!
+
 </div>
 
 ```toml

src/doc/rustc-dev-guide/src/tests/directives.md

@@ -248,11 +248,13 @@ ignoring debuggers.
 | `no-prefer-dynamic` | Don't use `-C prefer-dynamic`, don't build as a dylib via a `--crate-type=dylib` preset flag | `ui`, `crashes`           | N/A                                                                                        |
 
 <div class="warning">
+
 Tests (outside of `run-make`) that want to use incremental tests not in the
 incremental test-suite must not pass `-C incremental` via `compile-flags`, and
 must instead use the `//@ incremental` directive.
 
 Consider writing the test as a proper incremental test instead.
+
 </div>
 
 ### Rustdoc

src/doc/rustc-dev-guide/src/tests/minicore.md

@@ -7,9 +7,11 @@ ui/codegen/assembly test suites. It provides `core` stubs for tests that need to
 build for cross-compiled targets but do not need/want to run.
 
 <div class="warning">
+
 Please note that [`minicore`] is only intended for `core` items, and explicitly
 **not** `std` or `alloc` items because `core` items are applicable to a wider
 range of tests.
+
 </div>
 
 A test can use [`minicore`] by specifying the `//@ add-core-stubs` directive.

src/doc/rustc-dev-guide/src/tests/running.md

@@ -8,6 +8,7 @@ development because it takes a really long time. For local development, see the
 subsection after on how to run a subset of tests.
 
 <div class="warning">
+
 Running plain `./x test` will build the stage 1 compiler and then run the whole
 test suite. This not only include `tests/`, but also `library/`, `compiler/`,
 `src/tools/` package tests and more.
@@ -16,6 +17,7 @@ You usually only want to run a subset of the test suites (or even a smaller set
 of tests than that) which you expect will exercise your changes. PR CI exercises
 a subset of test collections, and merge queue CI will exercise all of the test
 collection.
+
 </div>
 
 ```text
@@ -116,8 +118,10 @@ By listing which test suites you want to run,
 you avoid having to run tests for components you did not change at all.
 
 <div class="warning">
+
 Note that bors only runs the tests with the full stage 2 build; therefore, while
 the tests **usually** work fine with stage 1, there are some limitations.
+
 </div>
 
 ### Run all tests using a stage 2 compiler