The assertion in `assert-long-condition.rs` used to be fail like this, all on
one line:
```
thread 'main' panicked at 'assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18\n + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0', tests/ui/macros/assert-long-condition.rs:7:5
```
The `\n` and subsequent indent is because the condition is pretty-printed, and
the pretty-printer inserts a newline. Printing the newline in this way is
arguably reasonable given that the message appears within single quotes, which
is very similar to a string literal.
However, after the assertion printing improvements that were released in 1.73,
the assertion now fails like this:
```
thread 'main' panicked at tests/ui/macros/assert-long-condition.rs:7:5:
assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18\n + 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0
```
Now that there are no single quotes around the pretty-printed condition, the
`\n` is quite strange.
This commit gets rid of the `\n`, by removing the `escape_debug` done on the
pretty-printed message. This results in the following:
```
thread 'main' panicked at tests/ui/macros/assert-long-condition.rs:7:5:
assertion failed: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18
+ 19 + 20 + 21 + 22 + 23 + 24 + 25 == 0
```
The overly-large indent is still strange, but that's a separate pretty-printing issue.
This change helps with #108341.
`Nonterminal`-related cleanups
In #114647 I am trying to remove `Nonterminal`. It has a number of preliminary cleanups that are worth merging even if #114647 doesn't merge, so let's do them in this PR.
r? `@petrochenkov`
Modify panic message for `assert_eq!`, `assert_ne!`, the currently unstable `assert_matches!`, as well as the corresponding `debug_assert_*` macros.
```rust
assert_eq!(1 + 1, 3);
assert_eq!(1 + 1, 3, "my custom message value={}!", 42);
```
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion failed: `(left == right)`
left: `2`,
right: `3`
```
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion failed: `(left == right)`
left: `2`,
right: `3`: my custom message value=42!
```
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion `left == right` failed
left: 2
right: 3
```
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion `left == right` failed: my custom message value=42!
left: 2
right: 3
```
This PR is a simpler subset of the #111030, but it does NOT stringify the original left and right source code assert expressions, thus should be faster to compile.
If a raw string was used in the `env!` invocation, then it should also
be shown in the diagnostic messages as a raw string.
Signed-off-by: David Wood <david@davidtw.co>
Suggest publicly accessible paths for items in private mod:
When encountering a path in non-import situations that are not reachable
due to privacy constraints, search for any public re-exports that the
user could use instead.
Track whether an import suggestion is offering a re-export.
When encountering a path with private segments, mention if the item at
the final path segment is not publicly accessible at all.
Add item visibility metadata to privacy errors from imports:
On unreachable imports, record the item that was being imported in order
to suggest publicly available re-exports or to be explicit that the item
is not available publicly from any path.
In order to allow this, we add a mode to `resolve_path` that will not
add new privacy errors, nor return early if it encounters one. This way
we can get the `Res` corresponding to the final item in the import,
which is used in the privacy error machinery.
- Either explicitly annotate `let x: () = expr;` where `x` has unit
type, or remove the unit binding to leave only `expr;` instead.
- Fix disjoint-capture-in-same-closure test
Remember names of `cfg`-ed out items to mention them in diagnostics
# Examples
## `serde::Deserialize` without the `derive` feature (a classic beginner mistake)
I had to slightly modify serde so that it uses explicit re-exports instead of a glob re-export. (Update: a serde PR was merged that adds the manual re-exports)
```
error[E0433]: failed to resolve: could not find `Serialize` in `serde`
--> src/main.rs:1:17
|
1 | #[derive(serde::Serialize)]
| ^^^^^^^^^ could not find `Serialize` in `serde`
|
note: crate `serde` has an item named `Serialize` but it is inactive because its cfg predicate evaluated to false
--> /home/gh-Nilstrieb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.160/src/lib.rs:343:1
|
343 | #[cfg(feature = "serde_derive")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
344 | pub use serde_derive::{Deserialize, Serialize};
| ^^^^^^^^^
= note: the item is gated behind the `serde_derive` feature
= note: see https://doc.rust-lang.org/cargo/reference/features.html for how to activate a crate's feature
```
(the suggestion is not ideal but that's serde's fault)
I already tested the metadata size impact locally by compiling the `windows` crate without any features. `800k` -> `809k`
r? `@ghost`
`#[cfg]`s are frequently used to gate crate content behind cargo
features. This can lead to very confusing errors when features are
missing. For example, `serde` doesn't have the `derive` feature by
default. Therefore, `serde::Serialize` fails to resolve with a generic
error, even though the macro is present in the docs.
This commit adds a list of all stripped item names to metadata. This is
filled during macro expansion and then, through a fed query, persisted
in metadata. The downstream resolver can then access the metadata to
look at possible candidates for mentioning in the errors.
This slightly increases metadata (800k->809k for the feature-heavy
windows crate), but not enough to really matter.
Shorten even more panic temporary lifetimes
Followup to #104134. As pointed out by `@bjorn3` in https://github.com/rust-lang/rust/pull/104134#pullrequestreview-1425585948, there are other cases in the panic macros which would also benefit from dropping their non-Send temporaries as soon as possible, avoiding pointlessly holding them across an await point.
For the tests added in this PR, here are the failures you get today on master without the macro changes in this PR:
<details>
<summary>tests/ui/macros/panic-temporaries-2018.rs</summary>
```console
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:52:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:52:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:53:18
|
LL | require_send(panic_str());
| ^^^^^^^^^^^ future returned by `panic_str` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:40:36
|
LL | f(panic!((NOT_SEND, "...").1)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:54:18
|
LL | require_send(unreachable_display());
| ^^^^^^^^^^^^^^^^^^^^^ future returned by `unreachable_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:45:31
|
LL | f(unreachable!(NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:54:18
|
LL | require_send(unreachable_display());
| ^^^^^^^^^^^^^^^^^^^^^ future returned by `unreachable_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:45:31
|
LL | f(unreachable!(NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: aborting due to 5 previous errors
```
</details>
<details>
<summary>tests/ui/macros/panic-temporaries.rs</summary>
```console
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries.rs:42:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries.rs:38:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries.rs:42:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries.rs:38:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: aborting due to 2 previous errors
```
</details>
r? bjorn3
Uplift `clippy::{drop,forget}_{ref,copy}` lints
This PR aims at uplifting the `clippy::drop_ref`, `clippy::drop_copy`, `clippy::forget_ref` and `clippy::forget_copy` lints.
Those lints are/were declared in the correctness category of clippy because they lint on useless and most probably is not what the developer wanted.
## `drop_ref` and `forget_ref`
The `drop_ref` and `forget_ref` lint checks for calls to `std::mem::drop` or `std::mem::forget` with a reference instead of an owned value.
### Example
```rust
let mut lock_guard = mutex.lock();
std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
// still locked
operation_that_requires_mutex_to_be_unlocked();
```
### Explanation
Calling `drop` or `forget` on a reference will only drop the reference itself, which is a no-op. It will not call the `drop` or `forget` method on the underlying referenced value, which is likely what was intended.
## `drop_copy` and `forget_copy`
The `drop_copy` and `forget_copy` lint checks for calls to `std::mem::forget` or `std::mem::drop` with a value that derives the Copy trait.
### Example
```rust
let x: i32 = 42; // i32 implements Copy
std::mem::forget(x) // A copy of x is passed to the function, leaving the
// original unaffected
```
### Explanation
Calling `std::mem::forget` [does nothing for types that implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the value will be copied and moved into the function on invocation.
-----
Followed the instructions for uplift a clippy describe here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
cc `@m-ou-se` (as T-libs-api leader because the uplifting was discussed in a recent meeting)
My type ascription
Oh rip it out
Ah
If you think we live too much then
You can sacrifice diagnostics
Don't mix your garbage
Into my syntax
So many weird hacks keep diagnostics alive
Yet I don't even step outside
So many bad diagnostics keep tyasc alive
Yet tyasc doesn't even bother to survive!
Migrate trivially translatable `rustc_parse` diagnostics
cc #100717
Migrate diagnostics in `rustc_parse` which are emitted in a single statement. I worked on this by expanding the lint introduced in #108760, although that isn't included here as there is much more work to be done to satisfy it
