Skip to content

Fix some warning blocks that contain Markdown #2446

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 2, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions src/autodiff/flags.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 3 additions & 1 deletion src/tests/ci.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 2 additions & 0 deletions src/tests/compiletest.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 2 additions & 0 deletions src/tests/directives.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 2 additions & 0 deletions src/tests/minicore.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
4 changes: 4 additions & 0 deletions src/tests/running.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down