[mir-opt] Disable the `ConsideredEqual` logic in SimplifyBranchSame opt
The logic is currently broken and we need to disable it to fix a beta
regression (see #76803)
r? `@oli-obk`
move guaranteed{ne,eq} implementation to compile-time machine
Currently, Miri needs a special hack to avoid using the core engine implementation of these intrinsics. That seems silly, so let's move them to the CTFE machine, which is the only machine that wants to use them.
I also added a reference to https://github.com/rust-lang/rust/issues/73722 as a warning to anyone who wants to adjust `guaranteed_eq`.
Improve E0118
- Changes the "base type" terminology to "nominal type" (according to the [reference](https://doc.rust-lang.org/stable/reference/items/implementations.html#inherent-implementations)).
- Suggests removing a reference, if one is present on the type.
- Clarify what is meant by a "nominal type".
closes#69392
This is my first not-entirely-trivial PR, so please let me know if I missed anything or if something could be improved. Though I probably won't be able to fix anything in the upcoming week.
Make graphviz font configurable
Alternative to PR #76776.
To change the graphviz output to use an alternative `fontname` value,
add a command line option like: `rustc --graphviz-font=monospace`.
r? @ecstatic-morse
Strip a single leading tab when rendering dataflow diffs
The `fmt_diff_with` formatter uses a tab to separate additions from subtractions. Strip it when rendering those diffs on separate lines.
r? @Mark-Simulacrum (since you're speedy)
Change error message for ty param in const
This PR introduces the following changes:
* Change error message for type param in a const expression when using
`min_const_generics`
* Change `ParamInNonTrivialAnonConst` to contain an extra `bool` used for
distinguishing whether the passed-in symbol is a type or a value.
Fixes#76701
Alternative to PR ##76776.
To change the graphviz output to use an alternative `fontname` value,
add a command line option like: `rustc --graphviz-font=monospace`.
improve const infer error
cc #72328
reduces it from
```
error[E0282]: type annotations needed
--> src/main.rs:17:5
|
17 | Foo.bar().bar().bar().bar().baz();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: unable to infer the value of a const parameter
```
to
```
error[E0282]: type annotations needed
--> $DIR/method-chain.rs:21:33
|
LL | Foo.bar().bar().bar().bar().baz();
| ^^^
|
= note: cannot infer the value of the const parameter `N`
```
r? @varkor
fix syntax error in suggesting generic constraint in trait parameter
suggest `where T: Foo` for the first bound on a trait, then suggest
`, T: Foo` when the suggested bound would add to an existing set of
`where` clauses. `where T: Foo` may be the first bound if `T` has a
default, because we'd rather suggest
```
trait A<T=()> where T: Copy
```
than
```
trait A<T: Copy=()>
```
for legibility reasons.
the test case i added here is derived from [this reproduction](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0bf3ace9f2a183d0bdbd748c6b8e3971):
```
struct B<T: Copy> {
t: T
}
trait A<T = ()> {
fn returns_constrained_type(&self, t: T) -> B<T> {
B { t }
}
}
```
where the suggested fix,
```
trait A<T = ()>, T: Copy { ... }
```
is in fact invalid syntax!
i also found an error in the existing suggestion for `trait Base<T = String>: Super<T>` where rustc would suggest `trait Base<T = String>: Super<T>, T: Copy`, but `T: Copy` is the first of the trait's `where` clauses and should be `where T: Copy` as well. the test for that suggestion expects invalid syntax, and has been revised to a compiler-pleasing `trait Base<T = String>: Super<T> where T: Copy`.
judging by https://github.com/rust-lang/rust/pull/70009 i'll.. cc @estebank ?
Introduce a PartitioningCx struct
This contains all the data used by the partitioning algorithm and allows that data to be used at each stage of the partitioning. This is useful for other approaches to partitioning which may want different pieces of the data available at each step.
cc @rust-lang/wg-incr-comp
Note when a a move/borrow error is caused by a deref coercion
Fixes#73268
When a deref coercion occurs, we may end up with a move error if the
base value has been partially moved out of. However, we do not indicate
anywhere that a deref coercion is occuring, resulting in an error
message with a confusing span.
This PR adds an explicit note to move errors when a deref coercion is
involved. We mention the name of the type that the deref-coercion
resolved to, as well as the `Deref::Target` associated type being used.
Detect overflow in proc_macro_server subspan
* Detect overflow in proc_macro_server subspan
* Add tests for overflow in Vec::drain
* Add tests for overflow in String / VecDeque operations using ranges
* Change error message for type param in a const expression when using
min_const_generics
* Change ParamInNonTrivialAnonConst to contain an extra bool used for
distinguishing whether the passed-in symbol is a type or a value.
use sort_unstable to sort primitive types
It's not important to retain original order if we have &[1, 1, 2, 3] for example.
clippy::stable_sort_primitive
More structured suggestions for boxed trait objects instead of impl Trait on non-coerceable tail expressions
When encountering a `match` or `if` as a tail expression where the
different arms do not have the same type *and* the return type of that
`fn` is an `impl Trait`, check whether those arms can implement `Trait`
and if so, suggest using boxed trait objects.
Use structured suggestion for `impl T` to `Box<dyn T>`.
Fix https://github.com/rust-lang/rust/issues/69107
