Extend `QueryStability` to handle `IntoIterator` implementations
This PR extends the `rustc::potential_query_instability` lint to check values passed as `IntoIterator` implementations.
Full disclosure: I want the lint to warn about this line (please see #138871 for why): aa8f0fd716/src/librustdoc/json/mod.rs (L261)
However, the lint warns about several other lines as well.
Final note: the functions `get_callee_generic_args_and_args` and `get_input_traits_and_projections` were copied directly from [Clippy's source code](4fd8c04da0/src/tools/clippy/clippy_lints/src/methods/unnecessary_to_owned.rs (L445-L496)).
Fix adjacent code
Fix duplicate warning; merge test into `tests/ui-fulldeps/internal-lints`
Use `rustc_middle::ty::FnSig::inputs`
Address two review comments
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109006991
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109058588
Use `Instance::try_resolve`
Import `rustc_middle::ty::Ty` as `Ty` rather than `MiddleTy`
Simplify predicate handling
Add more `#[allow(rustc::potential_query_instability)]` following rebase
Remove two `#[allow(rustc::potential_query_instability)]` following rebase
Address review comment
Update compiler/rustc_lint/src/internal.rs
Co-authored-by: lcnr <rust@lcnr.de>
rustdoc search: prefer stable items in search results
fixes https://github.com/rust-lang/rust/issues/138067
this does add a new field to the search index, but since we're only listing unstable items instead of adding a boolean flag to every item, it should only increase the search index size of sysroot crates, since those are the only ones using the `staged_api` feature, at least as far as the rust project is concerned.
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
rustdoc: Rearrange `Item`/`ItemInner`.
The `Item` struct is 48 bytes and contains a `Box<ItemInner>`;
`ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd
have one of the following.
- A single large struct, which avoids the allocation for the `Box`, but
can result in lots of wasted space in unused parts of a container like
`Vec<Item>`, `HashSet<Item>`, etc.
- Or, something like `struct Item(Box<ItemInner>)`, which requires the
`Box` allocation but gives a very small Item size, which is good for
containers like `Vec<Item>`.
`Item`/`ItemInner` currently gets the worst of both worlds: it always
requires a `Box`, but `Item` is also pretty big and so wastes space in
containers. It would make sense to push it in one direction or the
other. #138916 showed that the first option is a regression for rustdoc,
so this commit does the second option, which improves speed and reduces
memory usage.
r? `@GuillaumeGomez`
The `Item` struct is 48 bytes and contains a `Box<ItemInner>`;
`ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd
have one of the following.
- A single large struct, which avoids the allocation for the `Box`, but
can result in lots of wasted space in unused parts of a container like
`Vec<Item>`, `HashSet<Item>`, etc.
- Or, something like `struct Item(Box<ItemInner>)`, which requires the
`Box` allocation but gives a very small Item size, which is good for
containers like `Vec<Item>`.
`Item`/`ItemInner` currently gets the worst of both worlds: it always
requires a `Box`, but `Item` is also pretty big and so wastes space in
containers. It would make sense to push it in one direction or the
other. #138916 showed that the first option is a regression for rustdoc,
so this commit does the second option, which improves speed and reduces
memory usage.
rustdoc: use shorter paths as preferred canonical paths
This is a solution to [the `std::sync::poison` linking problem](https://github.com/rust-lang/rust/pull/134692#issuecomment-2560373308), and, in general, makes intra-doc links shorter and clearer.
> Done. This helped with the search, but not with the things like `MutexGuard`'s doc's reference to `Mutex::lock` being converted to the absolute (unstable) `std::sync::poison::Mutex` path.
cc `@tgross35`
r? `@GuillaumeGomez`
Don't keep the `external_traits` as shared mutable data between the
`DocContext` and `clean::Crate`. Instead, move the data over when necessary.
This allows us to get rid of a borrowck hack in the `DocVisitor`.
Remove `#[macro_use] extern crate tracing` from rustdoc and rustfmt
A follow-up to #129767 and earlier PRs doing this for `rustc_*` crates.
r? ```@GuillaumeGomez```
rustdoc: Cleanup `CacheBuilder` code for building search index
This code was very convoluted and hard to reason about. It is now (I hope) much
clearer and more suitable for both future enhancements and future cleanups.
I'm doing this as a precursor, with no UI changes, to changing rustdoc to
[ignore blanket impls][1] in type-based search.
[1]: https://github.com/rust-lang/rust/pull/128471#discussion_r1699475342
r? ``@notriddle``
Many of the code paths it handled were actually impossible. In other
cases, the various checks and transformations were spread around in such
a way that it was hard to tell what was going on.
rustdoc-search: single result for items with multiple paths
Part of #15723
Preview: https://notriddle.com/rustdoc-html-demo-9/reexport-dup/std/index.html?search=hashmap
This change uses the same "exact" paths as trait implementors and type alias inlining to track items with multiple reachable paths. This way, if you search for `vec`, you get only the `std` exports of it, and not the one from `alloc`.
It still includes all the items in the search index so that you can search for them by all available paths. For example, try `core::option` and `std::option`, and notice that the results page doesn't show duplicates, but still shows all the items in their respective crates.
This change uses the same "exact" paths as trait implementors
and type alias inlining to track items with multiple
reachable paths. This way, if you search for `vec`, you get
only the `std` exports of it, and not the one from `alloc`.
It still includes all the items in the search index so that
you can search for them by all available paths. For example,
try `core::option` and `std::option`, and notice that the
results page doesn't show duplicates, but still shows all
the items in their respective crates.
