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`
fix(expand): prevent infinity loop in macro containing only "///"
Fixes https://github.com/rust-lang/rust/issues/112342
Issue #112342 was caused by an infinity loop in `parse_tt_inner`, and the state of it is as follows:
- `matcher`: `[Sequence, Token(Doc), SequenceKleeneOpNoSep(op: ZeroOrMore), Eof]`
- loop:
| Iteration | Action |
| - | - |
| 0 | enter `Sequence`|
| 1 | enter `Token(Doc)` and `mp.idx += 1` had been executed |
| 2 | enter `SequenceKleeneOpNoSep` and reset `mp.idx` to `1` |
| 3 | enter `Token(Doc)` again|
To prevent the infinite loop, a check for whether it only contains `DocComment` in `check_lhs_no_empty_seq` had been added.
Add `-Ztrait-solver=next-coherence`
Flag that conditionally uses the trait solver *only* during coherence, for more testing and/or eventual partial-migration onto the trait solver (in the medium- to long-term).
* This still uses the selection context in some of the coherence methods I think, so it's not "complete". Putting this up for review and/or for further work in-tree.
* I probably need to spend a bit more time making sure that we don't sneakily create any other infcx's during coherence that also need the new solver enabled.
r? `@lcnr`
Fall back to bidirectional normalizes-to if no subst-relate candidate in alias-relate goal
Sometimes we get into the case where the choice of normalizes-to branch in alias-relate are both valid, but we cannot make a choice of which one to take because they are different -- either returning equivalent but permuted region constraints, or equivalent opaque type definitions but differing modulo normalization.
In this case, we can make progress by considering a fourth candidate where we compute both normalizes-to branches together and canonicalize that as a response. This is essentially the AND intersection of both normalizes-to branches. In an ideal world, we'd be returning something more like the OR intersection of both branches, but we have no way of representing that either for regions (maybe eventually) or opaques (don't see that happening ever).
This is incomplete, so like the subst-relate fallback it's only considered outside of coherence. But it doesn't seem like a dramatic strengthening of inference or anything, and is useful for helping opaque type inference succeed when the hidden type is a projection.
## Example
Consider the goal - `AliasRelate(Tait, <[i32; 32] as IntoIterator>::IntoIter)`.
We have three ways of currently solving this goal:
1. SubstRelate - fails because we can't directly equate the substs of different alias kinds.
2. NormalizesToRhs - `Tait normalizes-to <[i32; 32] as IntoIterator>::IntoIter`
* Ends up infering opaque definition - `Tait := <[i32; 32] as IntoIterator>::IntoIter`
3. NormalizesToLhs - `<[i32; 32] as IntoIterator>::IntoIter normalizes-to Tait`
* Find impl candidate, substitute the associated type - `std::array::IntoIter<i32, 32>`
* Equate `std::array::IntoIter<i32, 32>` and `Tait`
* Ends up infering opaque definition - `Tait := std::array::IntoIter<i32, 32>`
The problem here is that 2 and 3 are essentially both valid, since we have aliases that normalize on both sides, but due to lazy norm, they end up inferring different opaque type definitions that are only equal *after* normalizing them further.
---
r? `@lcnr`
Emit an error when return-type-notation is used with type/const params
These are not intended to be supported initially, even though the compiler supports them internally...
Fix suggestion for matching struct with `..` on both ends
### Before This PR
```
error: expected `}`, found `,`
--> src\main.rs:8:17
|
8 | Foo { .., x, .. } => (),
| --^
| | |
| | expected `}`
| `..` must be at the end and cannot have a trailing comma
|
help: move the `..` to the end of the field list
|
8 - Foo { .., x, .. } => (),
8 + Foo { .., x, , .. } => (),
|
```
### After This PR
```
error: expected `}`, found `,`
--> tests/ui/parser/issue-112188.rs:11:17
|
11 | let Foo { .., x, .. } = f; //~ ERROR expected `}`, found `,`
| --^-
| | |
| | expected `}`
| `..` must be at the end and cannot have a trailing comma
| help: remove the starting `..`
```
Fixes#112188.
Don't suggest changing `&self` and `&mut self` in function signature to be mutable when taking `&mut self` in closure
Current suggestion for when taking a mutable reference to `self` in a closure (as an upvar) will produce a machine-applicable suggestion to change the `self` in the function signature to `mut self`, but does not account for the specialness of implicit self in that it can already have `&` and `&mut` (see #111554). This causes the function signature to become `test(&mut mut self)` which does not seem desirable.
```
error[E0596]: cannot borrow `self` as mutable, as it is not declared as mutable
--> src/sound_player.rs:870:11
|
869 | pub fn test(&mut self) {
| ---- help: consider changing this to be mutable: `mut self`
870 | || test2(&mut self);
| ^^^^^^^^^ cannot borrow as mutable
```
This PR suppresses the "changing this to be mutable" suggestion if the implicit self is either `ImplicitSelfKind::ImmRef` or `ImplicitSelfKind::MutRef`.
Fixes#111554.
Rollup of 6 pull requests
Successful merges:
- #112081 (Avoid ICE on `#![doc(test(...)]` with literal parameter)
- #112196 (Resolve vars in result from `scrape_region_constraints`)
- #112303 (Normalize in infcx instead of globally for `Option::as_deref` suggestion)
- #112316 (Ensure space is inserted after keyword in `unused_delims`)
- #112318 (Merge method, type and const object safety checks)
- #112322 (Don't mention `IMPLIED_BOUNDS_ENTAILMENT` if signatures reference error)
Failed merges:
- #112251 (rustdoc: convert `if let Some()` that always matches to variable)
r? `@ghost`
`@rustbot` modify labels: rollup
Normalize in infcx instead of globally for `Option::as_deref` suggestion
fixes#112293
The projection may contain inference variables. These inference variables are local to the local inference context. Using `tcx.normalize_erasing_regions` doesn't work here because this method is global and does not have access to the inference context. It's therefore unable to deal with the inference variables. We normalize in the local inference context instead, which knowns about the inference variables.
The test looks a little different than the issue example, I made it more minimal and verified that it still ICEs on nightly.
Also contains a drive-by fix to properly compare the types.
r? `@compiler-errors`
Resolve vars in result from `scrape_region_constraints`
Since we perform `type_op::Normalize` in the local infcx when the new solver is enabled, vars aren't necessarily resolved, which triggers this ICE:
f85ab544df/compiler/rustc_infer/src/infer/nll_relate/mod.rs (L481)
There are more tests that go from ICE -> pass due to this change, but I just added revisions to a few for CI.
r? `@lcnr`
The projection may contain inference variables. These inference
variables are local to the local inference context. Using
`tcx.normalize_erasing_regions` doesn't work here because this method is
global and does not have access to the inference context. It's therefore
unable to deal with the inference variables. We normalize in the local
inference context instead, which knowns about the inference variables.
Show note for type ascription on a local binding interpreted as a constant pattern and not a new variable
Given the code
```rust
pub fn main() {
const y: i32 = 4;
let y: i32 = 3;
}
```
`y` in the let binding is actually interpreted as a constant pattern and is not a new variable, causing confusing diagnostics about refutable patterns in local binding.
This PR extends the note for type ascription of a constant pattern to `AscribeUserType` patterns which have `Constant` subpatterns.
Fixes#112269.
Given the code
```rust
pub fn main() {
const y: i32 = 4;
let y: i32 = 3;
}
```
`y` in the let binding is actually interpreted as a constant pattern
and is not a new variable, causing confusing diagnostics about
refutable patterns in local binding.
This commit extends the note for type ascription as a constant pattern
to `AscribeUserType` patterns as well.
The type inference of argument-position closures and async blocks
regressed in 1.70 as the evaluation order of async blocks changed, as
they are not implicitly wrapped in an identity-function anymore.
Fixes#112225 by making sure the evaluation order stays the same as it
used to.
only suppress coercion error if type is definitely unsized
we previously suppressed coercion errors when the return type was `dyn Trait` because we expect a far more descriptive `Sized` trait error to be emitted instead, however the code that does this suppression does not consider where-clause predicates since it just looked at the HIR. let's do that instead by creating an obligation and checking if it may hold.
fixes#110683fixes#112208
suggest `Option::as_deref(_mut)` on type mismatch in option combinator if it passes typeck
Fixes#106342.
This adds a suggestion to call `.as_deref()` (or `.as_deref_mut()` resp.) if typeck fails due to a type mismatch in the function passed to an `Option` combinator such as `.map()` or `.and_then()`.
For example:
```rs
fn foo(_: &str) {}
Some(String::new()).map(foo);
```
The `.map()` method requires its argument to satisfy `F: FnOnce(String)`, but it received `fn(&str)`, which won't pass. However, placing a `.as_deref()` before the `.map()` call fixes this since `&str == &<String as Deref>::Target`
Don't use `can_eq` in `derive(..)` suggestion for missing method
Unsatisfied predicates returned from method probe may reference inference vars from that probe, so drop this extra check I added in #110877 for more accurate derive suggestions...
Fixes#111500
