rustdoc: revert deref recur to resume inclusion of impl ExtTrait<Local> for ExtType
As discussed here: https://github.com/rust-lang/rust/issues/82465#issuecomment-829290384, Revert PR #80653 to resolve issue #82465.
Issue #82465 was we had stopped including certain trait implementations, namely implementations on an imported type of an imported trait *instantiated on a local type*. That bug was injected by PR #80653.
Reverting #80653 means we don't list all the methods that you have accessible via recursively applying `Deref`.
[Discussion in last week's rustc triage meeting](https://zulip-archive.rust-lang.org/238009tcompilermeetings/19557weekly2021042954818.html#236680594) led us to conclude that the bug was worse than the enhancement, and there was not an obvious fix for the bug itself. So for the short term we remove the enhancement, while in the long term we will work on figuring out a way to have our imported trait implementation cake and eat it too.
Improve CTFE UB validation error messages
As mentioned in https://github.com/rust-lang/rust/pull/86245#discussion_r650494012 this PR slightly improves the formatting of validation errors, to move the path to the error prefix.
From:
`type validation failed: encountered invalid vtable: size is bigger than largest supported object at .0`
To:
`type validation failed at .0: encountered invalid vtable: size is bigger than largest supported object`.
Fix force-warns to allow dashes.
The `--force-warns` flag was not allowing lint names with dashes, only supporting underscores. This changes it to allow dashes to match the behavior of the A/W/D/F flags.
Fix font weight
Fixes#86256.
I realized that the only cases where we actually needed to have bold text was inside `impl-items`.
cc `@camelid`
r? `@jsha`
Fix ICEs on invalid vtable size/alignment const UB errors
The invalid vtable size/alignment errors from `InterpCx::read_size_and_align_from_vtable` were "freeform const UB errors", causing ICEs when reaching validation. This PR turns them into const UB hard errors to catch them during validation and avoid that.
Fixes#86193
r? `@RalfJung`
(It seemed cleaner to have 2 variants but they can be merged into one variant with a message payload if you prefer that ?)
Update cargo
11 commits in aa8b09297bb3156b849e73db48af4cd050492fe6..44456677b5d1d82fe981c955dc5c67734b31f340
2021-06-09 00:28:53 +0000 to 2021-06-12 18:00:01 +0000
- Fix package_default_run test. (rust-lang/cargo#9577)
- Change how the fix_deny_warnings_but_not_others test works (rust-lang/cargo#9571)
- Add mising documentation regarding `cargo doc` (rust-lang/cargo#9565)
- Implement warning for ignored trailing arguments (rust-lang/cargo#9561)
- Make clippy happy (rust-lang/cargo#9569)
- Fix rustc/rustdoc config values to be config-relative. (rust-lang/cargo#9566)
- Update rustfix. (rust-lang/cargo#9567)
- Warn if an "all" target is specified, but we don't match anything (rust-lang/cargo#9549)
- add default_run to SerializedPackage (rust-lang/cargo#9550)
- respect user choice of lib/bin over heuristics (rust-lang/cargo#9522)
- Add a mean to mutably access the members of a workspace (rust-lang/cargo#9547)
Do not suggest to add type annotations for unnameable types
Consider this example:
```rust
const A = || 42;
struct S<T> { t: T }
const B: _ = S { t: || 42 };
```
This currently produces the following output:
```
error: missing type for `const` item
--> src/lib.rs:1:7
|
1 | const A = || 42;
| ^ help: provide a type for the item: `A: [closure@src/lib.rs:1:11: 1:16]`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> src/lib.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^
| |
| not allowed in type signatures
| help: replace `_` with the correct type: `S<[closure@src/lib.rs:4:21: 4:26]>`
error: aborting due to 2 previous errors
```
However, these suggestions are obviously useless, because the suggested types cannot be written down. With my changes, the suggestion is replaced with a note, because there is no simple fix:
```
error: missing type for `const` item
--> test.rs:1:7
|
1 | const A = || 42;
| ^
|
note: however, the inferred type `[closure@test.rs:1:11: 1:16]` cannot be named
--> test.rs:1:11
|
1 | const A = || 42;
| ^^^^^
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> test.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^ not allowed in type signatures
|
note: however, the inferred type `S<[closure@test.rs:4:21: 4:26]>` cannot be named
--> test.rs:4:14
|
4 | const B: _ = S { t: || 42 };
| ^^^^^^^^^^^^^^
error: aborting due to 2 previous errors
```
Detect incorrect vtable alignment during const eval
This PR fixes#86132 by detecting invalid alignment values for trait objects in the interpreter, and emitting an error about this conversion failure, to avoid the ICE.
I've noticed that the error emitted at a50d72158e/compiler/rustc_mir/src/interpret/traits.rs (L163-L166) doesn't seem to be present in the const-ub tests, so I've tried adding a test that triggers both of these cases: one for the invalid size, and another for the invalid alignment that #86132 tracks (I have found different magic values triggering different `Align::from_bytes` errors than the "power of 2" one, if need be).
However, when doing that, I *cannot* for the life of me figure out the correct incantation to make these 2 errors trigger with the "it is undefined behavior to use this value" message rather than the "any use of this value will cause an error" lint.
I've tried Oli's suggestions of different values, tuples and arrays, using the transparent wrapper trick from the other tests and I was only able to trigger the regular const-ub errors about the size of the vtable, or that the drop pointer was invalid. Maybe these "type validation failed" errors happen before this part of the interpreter is reached and there just needs some magic incorrect values to bypass them, I don't know.
Since this fixes an ICE, and if the constants are indeed used, these 2 tests will turn into a hard error, I thought I'd open the PR anyways. And if ```@RalfJung``` you know of a way I could manage that (if you think that these tests are worth checking that the `throw_ub_format!` does indeed create const-ub errors as we expect) I'd be grateful.
For that reason, r? ```@RalfJung``` and cc ```@oli-obk.```
Do not suggest ampmut if rhs is already mutable
Removes invalid suggestion in #85765, although it should highlight the user type instead of the local variable.
Looking at the comments of this line:
84b1005bfd/compiler/rustc_mir_build/src/build/matches/mod.rs (L2107)
It was intentionally set to `None`, causing it to highlight the local variable instead. I am not sure if I will be able to fix it.
Fixes#85765
Fix some diagnostic issues with const_generics_defaults feature gate
This PR makes a few changes:
- print out const param defaults in "lifetime ordering" errors rather than discarding them
- update `is_simple_text` to account for const params when checking if a type has no generics, this was causing a note to be failed to add to an error message
- fixes some diagnostic wording that incorrectly said there was ordering restrictions between type/const params despite the `const_generics_defaults` feature gate is active
Suggest a trailing comma if a 1-tuple is expected and a parenthesized expression is found
This pull request fixes#86100. The following code:
```rust
fn main() {
let t: (i32,) = (1);
}
```
currently produces:
```
warning: unnecessary parentheses around assigned value
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ^^^ help: remove these parentheses
|
= note: `#[warn(unused_parens)]` on by default
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
error: aborting due to previous error; 1 warning emitted
```
With my changes, I get the same warning and the following error:
```
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
help: use a trailing comma to create a tuple with one element
|
2 | let t: (i32,) = (1,);
| ^^^^
```
i.e. I have added a suggestion to add a trailing comma to create a 1-tuple. This suggestion is only issued if a 1-tuple is expected and the expression (`(1)` in the example above) is surrounded by parentheses and does not already have a tuple type. In this situation, I'd say that it is pretty likely that the user meant to create a tuple.
std: Stabilize wasm simd intrinsics
This commit performs two changes to stabilize Rust support for
WebAssembly simd intrinsics:
* The stdarch submodule is updated to pull in rust-lang/stdarch#1179.
* The `wasm_target_feature` feature gate requirement for the `simd128`
feature has been removed, stabilizing the name `simd128`.
This should conclude the FCP started on #74372 and...
Closes#74372
This commit performs two changes to stabilize Rust support for
WebAssembly simd intrinsics:
* The stdarch submodule is updated to pull in rust-lang/stdarch#1179.
* The `wasm_target_feature` feature gate requirement for the `simd128`
feature has been removed, stabilizing the name `simd128`.
This should conclude the FCP started on #74372 and...
Closes#74372
MVP for using rust-lld as part of cc
Will fix#71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa:🔙:link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl,-v` (thanks to bjorn3 on Zulip), I can see that lld is used, but I'm not sure how to inspect that output in a test.
Add the x86_64-gnu-stable builder
During the 1.52 release process we had to deal with some commits that passed the test suite on the nightly branch but failed on the beta or stable branch. In that case it was due to some UI tests including the channel name in the output, but other changes might also be dependent on the channel.
This commit adds a new CI job that runs the Linux x86_64 test suite with the stable branch, ensuring nightly changes also work as stable. To ensure the new job works the following other changes are present:
* The `ui-fulldeps/session-derive-errors.rs` test has been disabled on beta and stable, which required adding support for `// ignore-{channel}` and `// only-{channel}`.
* The `rustdoc/intra-doc/field.rs` has been fixed.
r? `@Mark-Simulacrum`
fixes https://github.com/rust-lang/release-team/issues/11
ignore test if rust-lld not found
create ld -> rust-lld symlink at build time instead of run time
for testing in ci
copy instead of symlinking
remove linux check
test for linker, suggestions from bjorn3
fix overly restrictive lld matcher
use -Zgcc-ld flag instead of -Clinker-flavor
refactor code adding lld to gcc path
revert ci changes
suggestions from petrochenkov
rename gcc_ld to gcc-ld in dirs
rustdoc: Print a warning if the diff when comparing to old nightlies is empty
This avoids confusing situations where it's unclear whether there's a
bug in the diff tool or not:
```
26: `@has` check failed
`XPATH PATTERN` did not match
// `@has` - '//code/a[`@href="{{channel}}/std/primitive.i32.html"]'` 'i32'
Encountered 6 errors
------------------------------------------
info: generating a diff against nightly rustdoc
failures:
[rustdoc] rustdoc/primitive-reexport.rs
```
Make copy/copy_nonoverlapping fn's again
Make copy/copy_nonoverlapping fn's again, rather than intrinsics.
This a short-term change to address issue #84297.
It effectively reverts PRs #81167#81238 (and part of #82967), #83091, and parts of #79684.
