Instead of linking to the old Rust Reference site on static.rust-lang.org,
link to the current website doc.rust-lang.org/stable/reference instead in
diagnostic about incorrect literals.
Uplift `clippy::cmp_nan` lint
This PR aims at uplifting the `clippy::cmp_nan` lint into rustc.
## `invalid_nan_comparisons`
~~(deny-by-default)~~ (warn-by-default)
The `invalid_nan_comparisons` lint checks comparison with `f32::NAN` or `f64::NAN` as one of the operand.
### Example
```rust,compile_fail
let a = 2.3f32;
if a == f32::NAN {}
```
### Explanation
NaN does not compare meaningfully to anything – not even itself – so those comparisons are always false.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
Ignore tests that hang in new solver
This makes it easier to run `--compare-mode=next-solver`, and we can revisit these tests later to find out how to make them less overflowy 😅
r? `@lcnr`
expand: Change how `#![cfg(FALSE)]` behaves on crate root
Previously it removed all other attributes from the crate root.
Now it removes only attributes below itself (during both regular expansion and pre-configuration).
So it becomes possible to configure some global crate properties even for fully unconfigured crates.
Fixes https://github.com/rust-lang/rust/issues/104633
Part of https://github.com/rust-lang/rust/issues/110082
increase the accuracy of effective visibilities calculation
Effective visibilities are calculated lazily due to performance restrictions. Therefore
- crate should be walked at least 1 time in `compute_effective_visibilities` pass
- Impl's should always be in the effective visibilities table
to ensure that the table is filled in correctly.
r? `@petrochenkov`
Previously it removed all other attributes from the crate root.
Now it removes only attributes below itself.
So it becomes possible to configure some global crate properties even for fully unconfigured crates.
Support float-like tuple indices in offset_of!()
Supports invocations like `offset_of!((((), ()), ()), 0.0)`. This `0.0` gets tokenized as float literal, so it has to be broken up again.
The code that did the breaking up was returning a finished `Expr`, while we need a `Ident`, so this PR splits up the `parse_expr_tuple_field_access_float` function into:
* a function that breaks up the float literal (similar to `TokenKind::break_two_token_op`, but we do access the parser during this splitting operation, so we keep it as an inherent function on the parser)
* and a function that constructs an `Expr` from it
The former we can then re-use in `offset_of` parsing. The edge cases especially involving whitespaces are tricky so this adds a bunch of new tests as well.
fixes#112204
Rollup of 3 pull requests
Successful merges:
- #112260 (Improve document of `unsafe_code` lint)
- #112429 ([rustdoc] List matching impls on type aliases)
- #112442 (Deduplicate identical region constraints in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Deduplicate identical region constraints in new solver
the new solver doesn't track whether we've already proven a goal like the fulfillment context's obligation forest does, so we may be instantiating a canonical response (and specifically, its nested region obligations) quite a few times.
This may lead to exponentially gathering up identical region constraints for things like auto traits, so let's deduplicate region constraints when in `compute_external_query_constraints`.
r? ``@lcnr``
Uplift `clippy::undropped_manually_drops` lint
This PR aims at uplifting the `clippy::undropped_manually_drops` lint.
## `undropped_manually_drops`
(warn-by-default)
The `undropped_manually_drops` lint check for calls to `std::mem::drop` with a value of `std::mem::ManuallyDrop` which doesn't drop.
### Example
```rust
struct S;
drop(std::mem::ManuallyDrop::new(S));
```
### Explanation
`ManuallyDrop` does not drop it's inner value so calling `std::mem::drop` will not drop the inner value of the `ManuallyDrop` either.
-----
Mostly followed the instructions for uplifting an clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::undropped_manually_drops` into rustc
Misc HIR typeck type mismatch tweaks
These are all intended to improve #112104, but I couldn't get it to actually suggest adding `as_ref` to the LHS of the equality expr without some hacks that I may play around with some more.
Each commit's title should explain what it's doing except for perhaps the last one, which addresses the bogus suggestion on #112104 itself.
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.
