Update E0393 to new error format
Fixes#35632.
Part of #35233.
r? @jonathandturner
and a wired thing is that if i add another label
```rust
.span_label(span, &format!("missing reference to `{}`", def.name))
.span_label(span, &format!("because of the default `Self` reference, type parameters must be specified on object types"))
```
and add a new note in the test case like
```rust
trait A<T=Self> {}
fn together_we_will_rule_the_galaxy(son: &A) {}
//~^ ERROR E0393
//~| NOTE missing reference to `T`
//~| NOTE because of the default `Self` reference, type parameters must be specified on object types
```
it will complain that
```
running 1 test
test [compile-fail] compile-fail/E0393.rs ... FAILED
failures:
---- [compile-fail] compile-fail/E0393.rs stdout ----
error: /Users/zjh/Documents/rustspace/rust/src/test/compile-fail/E0393.rs:13: unexpected "error": '13:43: 13:44: the type parameter `T` must be explicitly specified [E0393]'
unexpected errors (from JSON output): [
Error {
line_num: 13,
kind: Some(
Error
),
msg: "13:43: 13:44: the type parameter `T` must be explicitly specified [E0393]"
}
]
```
it is a little bit confusing and through the blog post we can use `//~^` and `//~|` to support multiple notes, @jonathandturner am i missing something here?
Change E0259 to the new error format
Fixes#35514 as part of #35233.
Sorry about creating a new PR I was having a lot of troubles squashing the commit because I didn't properly branch the new feature.
r? @GuillaumeGomez
Bonus format for E0194
Bonus fix for #35280. Part of #35233. Fixes#36057. Adding expanded notes/context for what trait a parameter shadows as part of E0194 error messages.
Errors for E0194 now look like this:
```
$> ./build/x86_64-apple-darwin/stage1/bin/rustc src/test/compile-fail/E0194.rs
error[E0194]: type parameter `T` shadows another type parameter of the same name
--> src/test/compile-fail/E0194.rs:13:26
|
11 | trait Foo<T> { //~ NOTE first `T` declared here
| - first `T` declared here
12 | fn do_something(&self) -> T;
13 | fn do_something_else<T: Clone>(&self, bar: T);
| ^ shadows another type parameter
error: aborting due to previous error
```
r? @jonathandturner
Add test for #14875
You can check this out in the playground https://is.gd/oVKC2T . It will fail on stable, but pass on nightly as @nagisa suggested on the issue.
Fixes#14875
add evocative examples for `BitOr` and `BitXor`
These are exactly equivalent to PR #35809, with one caveat: I do not believe there is a non-bitwise binary XOR operator in Rust, so here it's expressed as `(a || b) && !(a && b)`.
Alternative decompositions are `(a && !b) || (!a && b)` and `(a || b) && (!a || !b)`. Let me know if you think one of those would be clearer.
r? @GuillaumeGomez
accumulate vector and assert for RangeFrom and RangeInclusive examples
PR #35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
gdb: Fix pretty-printing special-cased Rust types
gdb trunk now reports fully qualified type names, just like lldb. Move lldb code for extracting unqualified names to shared file.
For current releases of gdb, `extract_type_name` should just be a no-op.
Fixes#35155
Use monotonic time in condition variables.
Configure condition variables to use monotonic time using
pthread_condattr_setclock on systems where this is possible.
This fixes the issue when thread waiting on condition variable is
woken up too late when system time is moved backwards.
These are exactly equivalent to PR #35809, with one caveat: I do not believe there is a non-bitwise binary "xor" operator in Rust, so here it's expressed as (a || b) && !(a && b).
r? @GuillaumeGomez
improved documentation a la PR #35993
