rustdoc: reference function signature types from the `p` array
This reduces the size of the function signature index, because it's common to have many functions that operate on the same types.
$ wc -c search-index-old.js search-index-new.js
5224374 search-index-old.js
3932314 search-index-new.js
By my math, this reduces the uncompressed size of the search index by 32%.
On compressed signatures, the wins are less drastic, a mere 8%:
$ wc -c search-index-old.js.gz search-index-new.js.gz
404532 search-index-old.js.gz
371635 search-index-new.js.gz
Remove feature `const_option` from std
This is part of the effort to reduce the number of unstable features used by std. This one is easy as it's only used in one place.
rustdoc-json: Allow Typedef to be different in sanity assert
Closes#98547
This fix is a natural extension of #98053.
r? `@notriddle`
(Since you reviewed the other PR.)
CC `@GuillaumeGomez`
`@rustbot` labels +A-rustdoc-json +T-rustdoc
Implement `Send` and `Sync` for `ThinBox<T>`
Just like `Box<T>`, `ThinBox<T>` owns its data on the heap, so it should
implement `Send` and `Sync` when `T` does.
This extends tracking issue #92791.
Refactor iter adapters with less macros
Just some code cleanup. Introduced a util `and_then_or_clear` for each of chain, flatten and fuse iter adapter impls. This reduces code nicely for flatten, but admittedly the other modules are more of a lateral move replacing macros with a function. But I think consistency across the modules and avoiding macros when possible is good.
translation: lint fix + more migration
- Unfortunately, the diagnostic lints are very broken and trigger much more often than they should. This PR corrects the conditional which checks if the function call being made is to a diagnostic function so that it returns in every intended case.
- The `rustc_lint_diagnostics` attribute is used by the diagnostic translation/struct migration lints to identify calls where non-translatable diagnostics or diagnostics outwith impls are being created. Any function used in creating a diagnostic should be annotated with this attribute so this PR adds the attribute to many more functions.
- Port the diagnostics from the `rustc_privacy` crate and enable the lints for that crate.
r? ``@compiler-errors``
Fix RSS reporting on macOS
> NOTE: This is a duplicate of #98164, which I closed because I borked my rustc fork
Currently, `rustc_data_structures::profiling::get_resident_set_size()` always returns `None` on macOS. This is because
macOS does not implement procfs used in the unix version of the function:
```rust
...
else if #[cfg(unix)] {
pub fn get_resident_set_size() -> Option<usize> {
let field = 1;
let contents = fs::read("/proc/self/statm").ok()?;
let contents = String::from_utf8(contents).ok()?;
let s = contents.split_whitespace().nth(field)?;
let npages = s.parse::<usize>().ok()?;
Some(npages * 4096)
}
...
```
The proposed solution uses libproc, and more specifically `proc_pidinfo`, which has been available on macOS since 10.5 if the function signature inside libproc.h is to be believed:
```c
int proc_pidinfo(int pid, int flavor, uint64_t arg, void *buffer, int buffersize) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
```
[RFC 2011] Optimize non-consuming operators
Tracking issue: https://github.com/rust-lang/rust/issues/44838
Fifth step of https://github.com/rust-lang/rust/pull/96496
The most non-invasive approach that will probably have very little to no performance impact.
## Current behaviour
Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.
```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`
if !(
{ ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
panic!( ... );
}
```
As such, some overhead is likely to occur (Specially with very large chains of conditions).
## New behaviour for non-consuming operators
When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition.
```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`
if !( a > 1 && b < 100 ) {
{ ***try capture `a`*** }
{ ***try capture `b`*** }
panic!( ... );
}
```
So the possible impact on the runtime execution time will be diminished.
r? ````@oli-obk````
Remove `MAX_SUGGESTION_HIGHLIGHT_LINES`
After #97798 the `MAX_SUGGESTION_HIGHLIGHT_LINES` constant doesn't really make sense since we always show full suggestions. This PR removes last usages of the constant and the constant itself.
r? ``@flip1995`` (this mostly does changes in clippy)
attempt to optimise vectored write
benchmarked:
old:
```
test io::cursor::tests::bench_write_vec ... bench: 68 ns/iter (+/- 2)
test io::cursor::tests::bench_write_vec_vectored ... bench: 913 ns/iter (+/- 31)
```
new:
```
test io::cursor::tests::bench_write_vec ... bench: 64 ns/iter (+/- 0)
test io::cursor::tests::bench_write_vec_vectored ... bench: 747 ns/iter (+/- 27)
```
More unsafe than I wanted (and less gains) in the end, but it still does the job
Only keep a single query for well-formed checking
There are currently 3 queries to perform wf checks on different item-likes. This complexity is not required.
This PR replaces the query by:
- one query per item;
- one query to invoke it for a whole module.
This allows to remove HIR `ParItemLikeVisitor`.
libcore tests: avoid int2ptr casts
We don't need any of these pointers to actually be dereferenceable so using `ptr::invalid` should be fine. And then we can run Miri with strict provenance enforcement on the tests.
Add triagebot mentions.
This migrates the configuration of mentions from highfive to triagebot.
I also fixed a few broken paths (error_codes.rs src/librustdoc/html/static/themes src/librustdoc/html/static/themes/ayu.css).
liballoc tests: avoid int2ptr cast
I think we don't need `ptr::from_exposed_addr` here; `ptr::invalid` should be enough for this test. (And this makes Miri less unhappy when running these tests.)
Fix "kind" for associated types in trait implementations in rustdoc JSON
Fixes https://github.com/rust-lang/rust/issues/81340.
Contrary to what is suggested in the issue, I really think we should distinguish between associated items and "normal" constants and types.
cc `@CraftSpider` `@SimonSapin`
r? `@notriddle`
