Improve async-await/generator obligation errors in some cases
Fixes#68112.
This change is best read one commit at a time (I add a test at the beginning and update it in each change after).
The `test2` function is a case I found while writing the test that we don't handle with this code yet. I don't attempt to fix it in this PR, but it's a good candidate for future work.
r? @davidtwco, @nikomatsakis
allow const generics in const fn
This was explicitly forbidden before. As we were unable to think of a reason
why this should still be the case, this check has been removed.
r? @eddyb
cc @varkor @Centril
Suggest .into() over try_into() when it would work
It would be better to suggest x.into() instead, which is shorter, cannot fail, and doesn't require importing a trait.
Tests have been added and made up to date.
Fixes#70851
ci: run mir-opt tests on PR CI also as 32-bit (for `EMIT_MIR_FOR_EACH_BIT_WIDTH`).
Background: #69916 and [`src/test/mir-opt/README.md`](https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md):
> By default 32 bit and 64 bit targets use the same dump files, which can be problematic in the
presence of pointers in constants or other bit width dependent things. In that case you can add
>
> ```
> // EMIT_MIR_FOR_EACH_BIT_WIDTH
> ```
>
> to your test, causing separate files to be generated for 32bit and 64bit systems.
However, if you change the output of such a test (intentionally or not), or if you add a test and it varies between 32-bit and 64-bit platforms, you have to run this command (for a x64 linux host):
`./x.py test --stage 1 --target x86_64-unknown-linux-gnu --target i686-unknown-linux-gnu --bless src/test/mir-opt`
Otherwise, bors trying to merge the PR will fail, since we test 32-bit targets there.
But we don't on PR CI, which means there's no way the PR author would know (unless they were burnt by this already and know what to look for).
This PR resolves that by running `mir-opt` tests for ~~`i686-unknown-linux-gnu`~~, on PR CI.
**EDIT**: switched to `armv5te-unknown-linux-gnueabi` to work around LLVM 7 crashes (see https://github.com/rust-lang/compiler-builtins/pull/311#issuecomment-612270089), found during testing.
cc @rust-lang/wg-mir-opt @rust-lang/infra
Fix warning for unused variables in or pattern (issue #67691)
Is this a good way to fix it?
Also, the tests fail, the "fixed" code output says `{ i, j }` instead of `{ i, j: _ }`, how can I fix that?
Handle `impl Trait` where `Trait` has an assoc type with missing bounds
When encountering a type parameter that needs more bounds the trivial case is `T` `where T: Bound`, but it can also be an `impl Trait` param that needs to be decomposed to a type param for cleaner code. For example, given
```rust
fn foo(constraints: impl Iterator) {
for constraint in constraints {
println!("{:?}", constraint);
}
}
```
the previous output was
```
error[E0277]: `<impl Iterator as std::iter::Iterator>::Item` doesn't implement `std::fmt::Debug`
--> src/main.rs:3:26
|
1 | fn foo(constraints: impl Iterator) {
| - help: consider further restricting the associated type: `where <impl Iterator as std::iter::Iterator>::Item: std::fmt::Debug`
2 | for constraint in constraints {
3 | println!("{:?}", constraint);
| ^^^^^^^^^^ `<impl Iterator as std::iter::Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug`
|
= help: the trait `std::fmt::Debug` is not implemented for `<impl Iterator as std::iter::Iterator>::Item`
= note: required by `std::fmt::Debug::fmt`
```
which is incorrect as `where <impl Iterator as std::iter::Iterator>::Item: std::fmt::Debug` is not valid syntax nor would it restrict the positional `impl Iterator` parameter if it were.
The output being introduced is
```
error[E0277]: `<impl Iterator as std::iter::Iterator>::Item` doesn't implement `std::fmt::Debug`
--> src/main.rs:3:26
|
3 | println!("{:?}", constraint);
| ^^^^^^^^^^ `<impl Iterator as std::iter::Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug`
|
= help: the trait `std::fmt::Debug` is not implemented for `<impl Iterator as std::iter::Iterator>::Item`
= note: required by `std::fmt::Debug::fmt`
help: introduce a type parameter with a trait bound instead of using `impl Trait`
|
LL | fn foo<T: Iterator>(constraints: T) where <T as std::iter::Iterator>::Item: std::fmt::Debug {
| ^^^^^^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This suggestion is correct and lead the user in the right direction: because you have an associated type restriction you can no longer use `impl Trait`, the only reasonable alternative is to introduce a named type parameter, bound by `Trait` and with a `where` binding on the associated type for the new type parameter `as Trait` for the missing bound.
*Ideally*, we would want to suggest something like the following, but that is not valid syntax today
```
error[E0277]: `<impl Iterator as std::iter::Iterator>::Item` doesn't implement `std::fmt::Debug`
--> src/main.rs:3:26
|
3 | println!("{:?}", constraint);
| ^^^^^^^^^^ `<impl Iterator as std::iter::Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug`
|
= help: the trait `std::fmt::Debug` is not implemented for `<impl Iterator as std::iter::Iterator>::Item`
= note: required by `std::fmt::Debug::fmt`
help: introduce a type parameter with a trait bound instead of using `impl Trait`
|
LL | fn foo(constraints: impl Iterator<Item: std::fmt::Debug>) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Fix#69638.
rustc: Add a warning count upon completion
This adds a `build completed with one warning/x warnings` message, similar to the already present `aborted due to previous error` message.
Rollup of 5 pull requests
Successful merges:
- #70644 (Clean up `ModuleConfig` initialization)
- #70937 (Fix staticlib name for *-pc-windows-gnu targets)
- #70996 (Add or_insert_with_key to Entry of HashMap/BTreeMap)
- #71020 (Store UNICODE_VERSION as a tuple)
- #71021 (Use write!-style syntax for MIR assert terminator)
Failed merges:
r? @ghost
Store UNICODE_VERSION as a tuple
Remove the UnicodeVersion struct containing
major, minor and update fields and replace it with
a 3-tuple containing the version number.
As the value of each field is limited to 255
use u8 to store them.
Remove the UnicodeVersion struct containing
major, minor and update fields and replace it with
a 3-tuple containing the version number.
As the value of each field is limited to 255
use u8 to store them.
tests encoding current behavior for various cases of "binding" to _.
The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed.
Cc #53114.
(This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)
Normalize function signature in function casting check procedure
Fixes#54094
```rust
trait Zoo {
type X;
}
impl Zoo for u16 {
type X = usize;
}
fn foo(abc: <u16 as Zoo>::X) {}
fn main() {
let x: *const u8 = foo as _;
}
```
Currently a `FnDef` need to be checked if it's able to cast to `FnPtr` before it is actually casted. But the signature of `FnPtr` target's associated types are not normalized:
96d77f0e5f/src/librustc_typeck/check/cast.rs (L536-L553)
However, during the coercion check, the signature of `FnPtr` target's associated types are normalized (The `<u16 as Zoo>::X` turns into `usize`).
96d77f0e5f/src/librustc_typeck/check/coercion.rs (L687-L729)
This inconsistency leads to the error:`Err(Sorts(ExpectedFound { expected: <u16 as Zoo>::X, found: usize }))`.
tests encoding current behavior for various cases of "binding" to _.
The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed.
Cc #53114.
(This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)
