Fix incorrect suggestions for E0605
Fixes#84598. Here is a simplified version of the problem presented in issue #84598:
```Rust
#![allow(unused_variables)]
#![allow(dead_code)]
trait T { fn t(&self) -> i32; }
unsafe fn foo(t: *mut dyn T) {
(t as &dyn T).t();
}
fn main() {}
```
The current output is:
```
error[E0605]: non-primitive cast: `*mut (dyn T + 'static)` as `&dyn T`
--> src/main.rs:7:5
|
7 | (t as &dyn T).t();
| ^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
7 | (&t as &dyn T).t();
| ^
```
This is incorrect, though: The cast will _not_ be valid when writing `&t` instead of `t`:
```
error[E0277]: the trait bound `*mut (dyn T + 'static): T` is not satisfied
--> t4.rs:7:6
|
7 | (&t as &dyn T).t();
| ^^ the trait `T` is not implemented for `*mut (dyn T + 'static)`
|
= note: required for the cast to the object type `dyn T`
```
The correct suggestion is `&*t`, which I have implemented in this pull request. Of course, this suggestion will always require an unsafe block, but arguably, that's what the user really wants if they're trying to cast a pointer to a reference.
In any case, claiming that the cast will be valid after implementing the suggestion is overly optimistic, as the coercion logic doesn't seem to resolve all nested obligations, i.e. the cast may still be invalid after implementing the suggestion. I have therefore rephrased the suggestion slightly ("consider borrowing the value" instead of "borrow the value for the cast to be valid").
Additionally, I have fixed another incorrect suggestion not mentioned in #84598, which relates to casting immutable references to mutable ones:
```rust
fn main() {
let mut x = 0;
let m = &x as &mut i32;
}
```
currently leads to
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
3 | let m = &mut &x as &mut i32;
| ^^^^
```
which is obviously incorrect:
```
error[E0596]: cannot borrow data in a `&` reference as mutable
--> t5.rs:3:13
|
3 | let m = &mut &x as &mut i32;
| ^^^^^^^ cannot borrow as mutable
```
I've changed the suggestion to a note explaining the problem:
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
note: this reference is immutable
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^
note: trying to cast to a mutable reference type
--> t5.rs:3:19
|
3 | let m = &x as &mut i32;
| ^^^^^^^^
```
In this example, it would have been even nicer to suggest replacing `&x` with `&mut x`, but this would be much more complex because we would have to take apart the expression to be cast (currently, we only look at its type), and `&x` could be stored in a variable, where such a suggestion would not even be directly applicable:
```rust
fn main() {
let mut x = 0;
let r = &x;
let m = r as &mut i32;
}
```
My solution covers this case, too.
Sync rustc_codegen_cranelift
The main highlight this sync is the removal of several dependencies, making compilation of cg_clif itself faster. There have also been a couple of new features like `#[link_section]` now supporting different segments for Mach-O binaries (thanks `@eggyal!)` and the `imported_main` feature, which is currently unstable.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Fix trait methods' toggle
A `<details>` tag wasn't closed on trait methods, which created broken DOM. I also used this occasion to only generate the toggle in case there is documentation on the method.
r? `@jsha`
Update cc
Recent commits have improved `cc`'s finding of MSVC tools on Windows. In particular it should help to address these issues: #83043 and #43468
readd capture disjoint fields gate
This readds a feature gate guard that was added in PR #83521. (Basically, there were unintended consequences to the code exposed by removing the feature gate guard.)
The root bug still remains to be resolved, as discussed in issue #85561. This is just a band-aid suitable for a beta backport.
Cc issue #85435
Note that the latter issue is unfixed until we backport this (or another fix) to 1.53 beta
stabilize member constraints
Stabilizes the use of "member constraints" in solving `impl Trait` bindings. This is a step towards stabilizing a "MVP" of "named impl Trait".
# Member constraint stabilization report
| Info | |
| --- | --- |
| Tracking issue | [rust-lang/rust#61997](https://github.com/rust-lang/rust/issues/61997) |
| Implementation history | [rust-lang/rust#61775] |
| rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) |
| Complications | [rust-lang/rust#61773] |
[rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775
[rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/61773
## Background
Member constraints are an extension to our region solver that was introduced to make async fn region solving tractable. There are used in situations like the following:
```rust
fn foo<'a, 'b>(...) -> impl Trait<'a, 'b> { .. }
```
The problem here is that every region R in the hidden type must be equal to *either* `'a` *or* `'b` (or `'static`). This cannot be expressed simply via 'outlives constriants' like `R: 'a`. Therefore, we introduce a 'member constraint' `R member of ['a, 'b]`.
These constraints were introduced in [rust-lang/rust#61775]. At the time, we kept them feature gated and used them only for `impl Trait` return types that are derived from `async fn`. The intention, however, was always to support them in other contexts once we had time to gain more experience with them.
**In the time since their introduction, we have encountered no surprises or bugs due to these member constraints.** They are tested extensively as part of every async function that involves multiple unrelated lifetimes in its arguments.
## Tests
The behavior of member constraints is covered by the following tests:
* [`src/test/ui/async-await/multiple-lifetimes`](20e032e650/src/test/ui/async-await/multiple-lifetimes) -- tests using the async await, which are mostly already stabilized
* [`src/test/ui/impl-trait/multiple-lifetimes.rs`](20e032e650/src/test/ui/impl-trait/multiple-lifetimes.rs)
* [`src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs`](20e032e650/src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs)
* [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs`](20e032e650/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs)
* [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs`](20e032e650/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs)
These tests cover a number of scenarios:
* `-> implTrait<'a, 'b>` with unrelated lifetimes `'a` and `'b`, as described above
* `async fn` that returns an `impl Trait` like the previous case, which desugars to a kind of "nested" impl trait like `impl Future<Output = impl Trait<'a, 'b>>`
## Potential concerns
There is a potential interaction with `impl Trait` on local variables, described in [rust-lang/rust#61773]. The challenge is that if you have a program like:
```rust=
trait Foo<'_> { }
impl Foo<'_> for &u32 { }
fn bar() {
let x: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1`
}
```
then we would wind up with `'0 member of ['1, 'static]`, where `'0` is the region variable in the hidden type (`&'0 u32`) and `'1` is the region variable in the bounds `Foo<'1>`. This is tricky because both `'0` and `'1` are being inferred -- so making them equal may have other repercussions.
That said, `impl Trait` in bindings are not stable, and the implementation is pretty far from stabilization. Moreover, the difficulty highlighted here is not due to the presence of member constraints -- it's inherent to the design of the language. In other words, stabilizing member constraints does not actually cause us to accept anything that would make this problem any harder.
So I don't see this as a blocker to stabilization of member constraints; it is potentially a blocker to stablization of `impl trait` in let bindings.
E0599 suggestions and elision of generic argument if no canditate is found
fixes#81576
changes: In error E0599 (method not found) generic argument are eluded if the method was not found anywhere. If the method was found in another inherent implementation suggest that it was found elsewhere.
Example
```rust
struct Wrapper<T>(T);
struct Wrapper2<T> {
x: T,
}
impl Wrapper2<i8> {
fn method(&self) {}
}
fn main() {
let wrapper = Wrapper(i32);
wrapper.method();
let wrapper2 = Wrapper2{x: i32};
wrapper2.method();
}
```
```
Error[E0599]: no method named `method` found for struct `Wrapper<_>` in the current scope
....
error[E0599]: no method named `method` found for struct `Wrapper2<i32>` in the current scope
...
= note: The method was found for Wrapper2<i8>.
```
I am not very happy with the ```no method named `test` found for struct `Vec<_, _>` in the current scope```. I think it might be better to show only one generic argument `Vec<_>` if there is a default one. But I haven't yet found a way to do that,
Optimize linkchecker and add report.
This makes three changes to the linkchecker:
* Adds a report displayed after it finishes.
* Improves the performance by caching all filesystem access. The linkchecker can take over a minute to run on some systems, and this should make it about 2-3 times faster.
* Added a few tests.
fix `matches!` and `assert_matches!` on edition 2021
Previously this code failed to compile on edition 2021. [(Playground)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=53960f2f051f641777b9e458da747707)
```rust
fn main() {
matches!((), ());
}
```
```
Compiling playground v0.0.1 (/playground)
error: `$pattern:pat` may be followed by `|`, which is not allowed for `pat` fragments
|
= note: allowed there are: `=>`, `,`, `=`, `if` or `in`
error: aborting due to previous error
error: could not compile `playground`
To learn more, run the command again with --verbose.
```
Post-monomorphization errors traces MVP
This PR works towards better diagnostics for the errors encountered in #85155 and similar.
We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate).
These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments, and validates these const arguments with a mechanism that triggers such PMEs.
(Not to mention that the errors happen during codegen, so only when building code that actually uses these code paths. Check builds don't trigger them, neither does unused code)
So in this PR, we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors, we print a diagnostic about the current collection step, so that the user has at least some context of which erroneous code and dependency triggered the error.
The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument:
```
note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>`
--> issue-85155.rs:11:24
|
11 | let _blended = _mm_blend_ps(a, b, 0x33);
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
Note that #85155 is a reduced version of a case happening in the wild, to indirect users of the `rustfft` crate, as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
<details>
```
error[E0080]: evaluation of constant value failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9
|
= note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info)
note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>`
--> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23
|
1314 | let blended = _mm_blend_ps(rows[0], rows[2], 0x33);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>`
--> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9
|
1859 | _mm_permute_pd(self, 0x05)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>`
--> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32
|
1863 | (_mm_movedup_pd(self), _mm_permute_pd(self, 0x0F))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0080`.
error: could not compile `rustfft`
To learn more, run the command again with --verbose.
```
</details>
I've developed and discussed this with them, so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course.
(I'm not sure we can say that this PR definitely closes issue 85155, as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli, but we decided to not include them in this PR for now)
Disallow shadowing const parameters
This pull request fixes#85348. Trying to shadow a `const` parameter as follows:
```rust
fn foo<const N: i32>() {
let N @ _ = 0;
}
```
currently causes an ICE. With my changes, I get:
```
error[E0530]: let bindings cannot shadow const parameters
--> test.rs:2:9
|
1 | fn foo<const N: i32>() {
| - the const parameter `N` is defined here
2 | let N @ _ = 0;
| ^ cannot be named the same as a const parameter
error: aborting due to previous error
```
This is the same error you get when trying to shadow a constant:
```rust
const N: i32 = 0;
let N @ _ = 0;
```
```
error[E0530]: let bindings cannot shadow constants
--> src/lib.rs:3:5
|
2 | const N: i32 = 0;
| ----------------- the constant `N` is defined here
3 | let N @ _ = 0;
| ^ cannot be named the same as a constant
error: aborting due to previous error
```
The reason for disallowing shadowing in both cases is described [here](https://github.com/rust-lang/rust/issues/33118#issuecomment-233962221) (the comment there only talks about constants, but the same reasoning applies to `const` parameters).
Update cargo
7 commits in 070e459c2d8b79c5b2ac5218064e7603329c92ae..e931e4796b61de593aa1097649445e535c9c7ee0
2021-05-11 18:12:23 +0000 to 2021-05-24 16:17:27 +0000
- Add `cargo:rustc-link-arg-bin` flag. (rust-lang/cargo#9486)
- Add a cargo-doc.browser config option (rust-lang/cargo#9473)
- Fix bug when with resolver = "1" non-virtual package was allowing unknown features (rust-lang/cargo#9437)
- Add GitHub link to contributor guide. (rust-lang/cargo#9493)
- Add temporary fix for rustup on windows in CI. (rust-lang/cargo#9498)
- 3 typos and some capitalization (rust-lang/cargo#9495)
- fix 6 typos (rust-lang/cargo#9484)
Fix bootstrap using host exe suffix for cargo
When attempting to cross compile rustc (for example, from Linux to Windows) and tell it to build cargo/tools, the following error occurs:
```
thread 'main' panicked at 'src.symlink_metadata() failed with No such file or directory (os error 2)', src/bootstrap/lib.rs:1196:24
```
Relevant part of stack trace:
<details>
```
2: bootstrap::Build::copy
at ./src/bootstrap/lib.rs:1196:24
3: <bootstrap::tool::ToolBuild as bootstrap::builder::Step>::run
at ./src/bootstrap/tool.rs:220:13
```
</details>
If I add `-vvv` (which seemed to be the recommended course for debugging a similar issue according to [zulip logs](https://zulip-archive.rust-lang.org/182449tcompilerhelp/19655failedtobootstrap.html)), it shows:
```
Copy ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release/cargo" to ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools-bin/cargo"
```
and when taking a look at the contents of `build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release` it contains `cargo.exe`, but no `cargo`.
I tried to study the surrounding code to make sure this was the intended behavior and while I can't be 100% certain, it does seem that using the exe suffix for the `compiler.host` target instead of the `target` target won't have the desired behavior when cross-compiling to/from Windows.
Avoid CJK legacy fonts in Windows
As metioned in #84035, the default serif CJK font in Windows is meh-looking.
To avoid this, we should use sans-serif font or provide CJK glyph supported font in `rustdoc.css`.
Bring back `x86_64-sun-solaris` target to rustup
Change #82216 removed now deprecated target `x86_64-sun-solaris` from CI, thus making it no longer possible to use `$ rustup target add x86_64-sun-solaris` to install given target (see #85098 for details). Since there should be a period of time between the deprecation and removal, this PR brings it back (while keeping the new one as well).
Please, correct me if I am wrong; my assumption that these Docker scripts are being used to build artifacts later used by `rustup` might be incorrect.
Closes#85098.
This test reproduces post-monomorphization errors one can encounter
when using incorrect immediate arguments to some of the stdarch
intrinsics using const generics.
deal with `const_evaluatable_checked` in `ConstEquate`
Failing to evaluate two constants which do not contain inference variables should not result in ambiguity.
Remove doubled braces in non_exhaustive structs’ documentation text.
In commit 4b80687854 (part of Rust 1.52.1) many calls to `write!(w,` were replaced with `w.write_str(`, but this one contained braces that were doubled to escape them when taken as a format string, and so changing the call without changing the text caused them to become doubled in the final HTML output.
I examined `print_item.rs` and the diff of that prior commit for any other occurrences of this mistake and I did not find any.
Use TargetTriple::from_path in rustdoc
This fixes the problem reported in https://github.com/Rust-for-Linux/linux/pull/272 where rustdoc requires the absolute path of a target spec json instead of accepting a relative path like rustc.
