rustdoc-search: search never type with `!`
This feature extends rustdoc to support the syntax that most users will naturally attempt to use to search for diverging functions. Part of #60485
It's already possible to do this search with `primitive:never`, but that's not what the Rust language itself uses, so nobody will try it if they aren't told or helped along.
fix(resolve): update shadowed_glob more precision
- Fixes#109153
- Fixes#109962
## Why does it panic?
We use #109153 as an illustration.
The process of `resolve_imports` is:
| Iter | resolve | resolution of **`(Mod(root), Ident(bar) in type ns)`** |
| - | - | - |
| 0 | `use foo::*` | `binding` -> foo::bar, `shallowed_glob` -> `None` |
| 1 | `use bar::bar` | `binding` -> foo::bar::bar, `shallowed_glob` -> foo::bar |
| 2 | `use bar::*` | `binding` -> foo::bar::bar, `shallowed_glob` -> foo::bar::bar::bar |
So during `finalize_import`, the `root::bar` in `use bar::bar` had been pointed to `foo::bar::bar::bar`, which is different from the `initial_module` valued of `foo::bar`, therefore, the panic had been triggered.
## Try to solve it
~I think #109153 should check-pass rather than throw an ambiguous error. Following this idea, there are two ways to solve this problem:~
~1. Give up the `initial_module` and update `import.imported_module` after each resolution update. However, I think this method may have too much impact.~
~2. Do not update the `shadowed_glob` when it is defined.~
~To be honest, I am not sure if this is the right way to solve this ICE. Perhaps there is a better resolution.~
Edit: we had made the `resolution.shadowed_glob` update more detailed.
r? `@petrochenkov`
Make struct layout not depend on unsizeable tail
fixes (after backport) https://github.com/rust-lang/rust/issues/112048
Since unsizing `Ptr<Foo<T>>` -> `Ptr<Foo<U>` just copies the pointer and adds the metadata, the layout of `Foo` must not depend on niches in and alignment of the tail `T`.
Nominating for beta 1.71, because it will have this issue: `@rustbot` label beta-nominated
Add MVP suggestion for `unsafe_op_in_unsafe_fn`
Rebase of https://github.com/rust-lang/rust/pull/99827
cc tracking issue https://github.com/rust-lang/rust/issues/71668
No real changes since the original PR, just migrated the new suggestion to use fluent messages and added a couple more testcases, AFAICT from the discussion there were no outstanding changes requested.
Adjust UI tests for `unit_bindings` lint
- Explicitly annotate `let x: () = expr;` where `x` has unit type, or remove the unit binding to leave only `expr;` instead.
- Use `let () = init;` or `let pat = ();` where appropriate.
- Fix disjoint-capture-in-same-closure test which wasn't actually testing a closure: `tests/ui/closures/2229_closure_analysis/run_pass/disjoint-capture-in-same-closure.rs`.
Note that unfortunately there's *a lot* of UI tests, there are a couple of places where I may have left something like `let (): ()` (this is not needed but is left over from an ealier version of the lint) which is bad style.
This PR is to help with the `unit_bindings` lint at #112380.
This feature extends rustdoc to support the syntax that most users will
naturally attempt to use to search for diverging functions.
Part of #60485
It's already possible to do this search with `primitive:never`, but
that's not what the Rust language itself uses, so nobody will try it if
they aren't told or helped along.
Suggest using `ptr::null_mut` when user provided `ptr::null` to a function expecting `ptr::null_mut`
```
error[E0308]: mismatched types
--> $DIR/ptr-null-mutability-suggestions.rs:9:24
|
LL | expecting_null_mut(ptr::null());
| ------------------ ^^^^^^^^^^^
| | |
| | types differ in mutability
| | help: consider using `core::ptr::null_mut` instead: `core::ptr::null_mut()`
| arguments to this function are incorrect
|
= note: expected raw pointer `*mut u8`
found raw pointer `*const _`
note: function defined here
--> $DIR/ptr-null-mutability-suggestions.rs:6:4
|
LL | fn expecting_null_mut(_: *mut u8) {}
| ^^^^^^^^^^^^^^^^^^ ----------
```
Closes#85184.
- 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
Dont compute `opt_suggest_box_span` span for TAIT
Fixes#112434
Also a couple more commits on top, pruning some dead code and fixing another weird suggestion encountered in the above issue.
iat selection: normalize self ty & completely erase bound vars
Erase bound vars (most notably late-bound regions) irrespective of their binding level instead of just at the innermost one.
Fixes#111404.
rustdoc: re-elide cross-crate default trait-object lifetime bounds
Hide trait-object lifetime bounds (re-exported from an external crate) if they coincide with [their default](https://doc.rust-lang.org/reference/lifetime-elision.html#default-trait-object-lifetimes).
Partially addresses #44306. Follow-up to #103885. [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/clean_middle_ty.3A.20I.20need.20to.20add.20a.20parameter/near/307143097).
Most notably, if `std` exported something from `core` containing a type like `Box<dyn Fn()>`, then it would now be rendered as `Box<dyn Fn(), Global>` instead of `Box<dyn Fn() + 'static, Global>` (hiding `+ 'static` as it is the default in this case). Showing `Global` here is a separate issue, #80379, which is on my agenda.
Note that I am not really fond of the fact that I had to add a parameter to such a widely used function (30+ call sites) to address such a niche bug.
CC `@GuillaumeGomez`
Requesting a review from a compiler contributor or team member as recommended on Zulip.
r? compiler
---
`@rustbot` label T-compiler T-rustdoc A-cross-crate-reexports
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.
Adjust span labels for `HIDDEN_GLOB_REEXPORTS`
Addresses https://github.com/rust-lang/rust/pull/111378#issuecomment-1581226063.
### Before This PR
The possibility that the private item comes before the glob re-export was not account for, causing the span label messages to say "but private item here shadows it" before "the name `Foo` in the type namespace is supposed to be publicly re-exported here".
### After This PR
```rust
warning: private item shadows public glob re-export
--> $DIR/hidden_glob_reexports.rs:9:5
|
LL | struct Foo;
| ^^^^^^^^^^^ the private item here shadows the name `Foo` in the type namespace
...
LL | pub use self::inner::*;
| -------------- but it is supposed to be publicly re-exported here
|
= note: `#[warn(hidden_glob_reexports)]` on by default
warning: private item shadows public glob re-export
--> $DIR/hidden_glob_reexports.rs:27:9
|
LL | pub use self::inner::*;
| -------------- the name `Foo` in the type namespace is supposed to be publicly re-exported here
LL |
LL | use self::other::Foo;
| ^^^^^^^^^^^^^^^^ but the private item here shadows it
```
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
