This new way is **slightly** less expressive (I would be shocked if it
affects any code, though) when it comes to higher-ranked bounds or a
few other weird tricks. But we don't handle those consistently
regardless, and the new way does not require normalization and is just
wildly simpler.
When we get around to resolving regions, we really ought to take region
obligations into account. There is one case where they are presently
being ignored. Keep ignoring them there for now but leave a TODO.
rustc_driver: expose a way to override query providers in CompileController.
This API has been a long-time coming and will probably become the main method for custom drivers (that is, binaries other than `rustc` itself that use `librustc_driver`) to adapt the compiler's behavior.
rustc_mir: hardcode pass list internally and remove premature pluggability.
Fixes#41712 by moving the MIR pass lists from `rustc_driver` to `rustc_mir`.
The application of the passes is done with the `rustc_mir::transform::run_passes` macro, which is public, as are all the passes AFAIK, and can be used to apply MIR passes outside of `rustc_mir`.
With the ability to override query providers through the `rustc_driver` (orthogonal to, and not included in this PR), custom drivers will be able to substitute the entire pass list if they want to.
**EDIT**: the aforementioned ability is added by #45944.
r? @nikomatsakis
incr.comp.: Don't crash in DepGraph::try_mark_green() when encountering a removed input node.
Fixes a small regression that was introduced in #45867.
r? @nikomatsakis
deduplicate projection error (E0271) messages
The `ErrorId` variant takes a u16 so that `DiagnosticMessageId` can retain
its `Copy` status (the present author's first choice having been the "EXXX"
code as a string).
The duplicated "type mismatch resolving `{}`" literal is unfortunate, but
the `struct_span_err!` macro (which we want to mark that error code as
used) is fussy about taking a literal, and the one-time-diagnostics set
needs an owned string.
This is concerning #33941 and probably #45805!
r? @estebank
MIR-borrowck: fix diagnostics for closures
Emit notes for captured variables in the same manner as AST borrowck.
```
error[E0499]: cannot borrow `x` as mutable more than once at a time (Ast)
--> $DIR/borrowck-closures-two-mut.rs:24:24
|
23 | let c1 = to_fn_mut(|| x = 4);
| -- - previous borrow occurs due to use of `x` in closure
| |
| first mutable borrow occurs here
24 | let c2 = to_fn_mut(|| x = 5); //~ ERROR cannot borrow `x` as mutable more than once
| ^^ - borrow occurs due to use of `x` in closure
| |
| second mutable borrow occurs here
25 | }
| - first borrow ends here
error[E0499]: cannot borrow `x` as mutable more than once at a time (Mir)
--> $DIR/borrowck-closures-two-mut.rs:24:24
|
23 | let c1 = to_fn_mut(|| x = 4);
| -- - previous borrow occurs due to use of `x` in closure
| |
| first mutable borrow occurs here
24 | let c2 = to_fn_mut(|| x = 5); //~ ERROR cannot borrow `x` as mutable more than once
| ^^ - borrow occurs due to use of `x` in closure
| |
| second mutable borrow occurs here
25 | }
| - first borrow ends here
```
Fixes#45362.
The `ErrorId` variant takes a u16 so that `DiagnosticMessageId` can retain
its `Copy` status (the present author's first choice having been the "EXXX"
code as a string).
The duplicated "type mismatch resolving `{}`" literal is unfortunate, but
the `struct_span_err!` macro (which we want to mark that error code as
used) is fussy about taking a literal, and the one-time-diagnostics set
needs an owned string.
This is concerning #33941 and probably #45805!
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.
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.
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
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
