diff --git a/rust-version b/rust-version
index 6baf43397..fe858d6fa 100644
--- a/rust-version
+++ b/rust-version
@@ -1 +1 @@
-493c38ba371929579fe136df26eccd9516347c7a
+2ea33b591050c4ca1a3752830b29112638faecf6
diff --git a/src/notification-groups/about.md b/src/notification-groups/about.md
index 74629aa08..af305f010 100644
--- a/src/notification-groups/about.md
+++ b/src/notification-groups/about.md
@@ -23,7 +23,7 @@ Here's the list of the notification groups:
- [ARM](./arm.md)
- [Cleanup Crew](./cleanup-crew.md)
- [Emscripten](./emscripten.md)
-- [LLVM](./llvm.md)
+- [LLVM Icebreakers](./llvm.md)
- [RISC-V](./risc-v.md)
- [WASI](./wasi.md)
- [WebAssembly](./wasm.md)
@@ -83,7 +83,7 @@ group. For example:
@rustbot ping arm
@rustbot ping cleanup-crew
@rustbot ping emscripten
-@rustbot ping llvm
+@rustbot ping icebreakers-llvm
@rustbot ping risc-v
@rustbot ping wasi
@rustbot ping wasm
diff --git a/src/notification-groups/llvm.md b/src/notification-groups/llvm.md
index 2eff63713..9d0087285 100644
--- a/src/notification-groups/llvm.md
+++ b/src/notification-groups/llvm.md
@@ -1,13 +1,16 @@
-# LLVM Notification group
+# LLVM Icebreakers Notification group
**Github Label:** [A-LLVM]
-**Ping command:** `@rustbot ping llvm`
+**Ping command:** `@rustbot ping icebreakers-llvm`
[A-LLVM]: https://github.com/rust-lang/rust/labels/A-LLVM
-The "LLVM Notification Group" are focused on bugs that center around LLVM.
-These bugs often arise because of LLVM optimizations gone awry, or as
-the result of an LLVM upgrade. The goal here is:
+*Note*: this notification group is *not* the same as the LLVM working group
+(WG-llvm).
+
+The "LLVM Icebreakers Notification Group" are focused on bugs that center around
+LLVM. These bugs often arise because of LLVM optimizations gone awry, or as the
+result of an LLVM upgrade. The goal here is:
- to determine whether the bug is a result of us generating invalid LLVM IR,
or LLVM misoptimizing;
diff --git a/src/tests/ci.md b/src/tests/ci.md
index cded565d6..c04f296ba 100644
--- a/src/tests/ci.md
+++ b/src/tests/ci.md
@@ -180,6 +180,8 @@ their results can be seen [here](https://github.com/rust-lang-ci/rust/actions),
although usually you will be notified of the result by a comment made by bors on
the corresponding PR.
+Note that if you start the default try job using `@bors try`, it will skip building several `dist` components and running post-optimization tests, to make the build duration shorter. If you want to execute the full build as it would happen before a merge, add an explicit `try-job` pattern with the name of the default try job (currently `dist-x86_64-linux`).
+
Multiple try builds can execute concurrently across different PRs.
diff --git a/src/tests/ui.md b/src/tests/ui.md
index 728ea3de4..8f1df001b 100644
--- a/src/tests/ui.md
+++ b/src/tests/ui.md
@@ -202,6 +202,12 @@ several ways to match the message with the line (see the examples below):
* `~|`: Associates the error level and message with the *same* line as the
*previous comment*. This is more convenient than using multiple carets when
there are multiple messages associated with the same line.
+* `~v`: Associates the error level and message with the *next* error
+ annotation line. Each symbol (`v`) that you add adds a line to this, so `~vvv`
+ is three lines below the error annotation line.
+* `~?`: Used to match error levels and messages with errors not having line
+ information. These can be placed on any line in the test file, but are
+ conventionally placed at the end.
Example:
@@ -270,10 +276,35 @@ fn main() {
//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023]
```
+#### Positioned above error line
+
+Use the `//~v` idiom with number of v's in the string to indicate the number
+of lines below. This is typically used in lexer or parser tests matching on errors like unclosed
+delimiter or unclosed literal happening at the end of file.
+
+```rust,ignore
+// ignore-tidy-trailing-newlines
+//~v ERROR this file contains an unclosed delimiter
+fn main((ؼ
+```
+
+#### Error without line information
+
+Use `//~?` to match an error without line information.
+`//~?` is precise and will not match errors if their line information is available.
+It should be preferred to using `error-pattern`, which is imprecise and non-exhaustive.
+
+```rust,ignore
+//@ compile-flags: --print yyyy
+
+//~? ERROR unknown print request: `yyyy`
+```
+
### `error-pattern`
-The `error-pattern` [directive](directives.md) can be used for messages that don't
-have a specific span.
+The `error-pattern` [directive](directives.md) can be used for runtime messages, which don't
+have a specific span, or for compile time messages if imprecise matching is required due to
+multi-line platform specific diagnostics.
Let's think about this test:
@@ -300,7 +331,9 @@ fn main() {
}
```
-But for strict testing, try to use the `ERROR` annotation as much as possible.
+But for strict testing, try to use the `ERROR` annotation as much as possible,
+including `//~?` annotations for diagnostics without span.
+For compile time diagnostics `error-pattern` should very rarely be necessary.
### Error levels
@@ -353,7 +386,7 @@ would be a `.mir.stderr` and `.thir.stderr` file with the different outputs of
the different revisions.
> Note: cfg revisions also work inside the source code with `#[cfg]` attributes.
->
+>
> By convention, the `FALSE` cfg is used to have an always-false config.
## Controlling pass/fail expectations