Improve SubSupConflict with a named and an anonymous lifetime parameter #42701
Hello!
This fixes#42701.
## UPDATE 01
Tests are producing different results between different env builds.
This inconsistency might take a long time to investigate and fix. So, be patient
## UPDATE 02
Changed an `FxHashMap` with a `BTreeMap`. Inconsistency seems to be resolved for now.
Fix MIR CopyPropagation errneously propagating assignments to function args
Compiling this code with MIR CopyPropagation activated will result in printing `5`,
because CopyProp errneously propagates the assignment of `5` to all `x`:
```rust
fn bar(mut x: u8) {
println!("{}", x);
x = 5;
}
fn main() {
bar(123);
}
```
If a local is propagated, it will result in an ICE at trans due to an use-before-def:
```rust
fn dummy(x: u8) -> u8 { x }
fn foo(mut x: u8) {
x = dummy(x); // this will assign a local to `x`
}
```
Currently CopyProp conservatively gives up if there are multiple assignments to a local,
but it is not took into account that arguments are already assigned from the beginning.
This PR fixes the problem by preventing propagation of assignments to function arguments.
Make saturating u128 -> f32 casts the default behavior
... rather than being gated by `-Z saturating-float-casts`. There are several reasons for this:
1. Const eval already implements this behavior.
2. Unlike with float->int casts, this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in.
3. Having two orthogonal features under one flag is silly, and never should have happened in the first place.
4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any).
Fixes#41799
Implement arbitrary_self_types
r? @arielb1
cc @nikomatsakis
Partial implementation of #44874. Supports trait and struct methods with arbitrary self types, as long as the type derefs (transitively) to `Self`. Doesn't support raw-pointer `self` yet.
Methods with non-standard self types (i.e. anything other than `&self, &mut self, and Box<Self>`) are not object safe, because dynamic dispatch hasn't been implemented for them yet.
I believe this is also a (partial) fix for #27941.
Accept interpolated patterns in trait method parameters
Permit this, basically
```rust
macro_rules! m {
($pat: pat) => {
trait Tr {
fn f($pat: u8) {}
}
}
}
```
it previously caused a parsing error during expansion because trait methods accept only very restricted set of patterns during parsing due to ambiguities caused by [anonymous parameters](https://github.com/rust-lang/rust/issues/41686), and this set didn't include interpolated patterns.
Some outdated messages from "no patterns allowed" errors are also removed.
Addresses https://github.com/rust-lang/rust/issues/35203#issuecomment-341937159
The return value in these tests is just being used to generate extra
code so that it can be detected in the test script, which is just
counting lines in the assembly output.
Fix checking of auto trait bounds in trait objects.
Any auto trait is allowed in trait object bounds. Fix duplicate check of type and lifetime parameter count, which we were [emitting twice](https://play.rust-lang.org/?gist=37dbbdbbec62dec423bb8f6d92f137cc&version=stable).
Note: This was the last use of `Send` in the compiler, meaning after a new `stage0` we could remove the `send` lang item.
With rustc now emitting "ud2" on unreachable code, a "return nothing"
sequence may take the same number of lines as an "unreachable" sequence
in assembly code. This test is testing that intrinsics::unreachable()
works by testing that it reduces the number of lines in the assembly
code. Fix it by adding a return value, which requires an extra
instruction in the reachable case, which provides the test what it's
looking for.
rustc: add item name to deprecated lint warning
It can sometimes be difficult to know what is actually deprecated when you have `foo.bar()` and `bar` comes from a trait in another crate.
... rather than being gated by -Z saturating-float-casts.
There are several reasons for this:
1. Const eval already implements this behavior.
2. Unlike with float->int casts, this behavior is uncontroversially the
right behavior and it is not as performance critical. Thus there is no
particular need to make the bug fix for u128->f32 casts opt-in.
3. Having two orthogonal features under one flag is silly, and never
should have happened in the first place.
4. Benchmarking float->int casts with the -Z flag should not pick up
performance changes due to the u128->f32 casts (assuming there are any).
Fixes#41799
Allow a trailling comma in assert_eq/ne macro
From Rust beginners IRC:
<???> It sure does annoy me that assert_eq!() does not accept a trailing comma after the last argument.
<???> ???: File an issue against https://github.com/rust-lang/rust and CC @rust-lang/libs
Figured that might as well submit it. Will become insta-stable after merging (danger zone).
cc @rust-lang/libs
Fix help for duplicated names: `extern crate (...) as (...)`
On the case of duplicated names caused by an `extern crate` statement
with a rename, don't include the inline suggestion, instead using a span
label with only the text to avoid incorrect rust code output.
Fix#45829.
Add error for `...` in expressions
Follow-up to https://github.com/rust-lang/rust/pull/44709
Tracking issue: https://github.com/rust-lang/rust/issues/28237
* Using `...` in expressions was a warning, now it's an error
* The error message suggests using `..` or `..=` instead, and explains the difference
* Updated remaining occurrences of `...` to `..=`
r? petrochenkov
Normalizing method signatures can unify inference variables, which can
cause receiver unification to fail. Unify the receivers first to avoid
that.
Fixes#36701.
Fixes#45801.
Fixes#45855.
