| Age | Commit message (Collapse) | Author | Lines |
|
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.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #137816 (attempt to support `BinaryFormat::Xcoff` in `naked_asm!`)
- #138109 (make precise capturing args in rustdoc Json typed)
- #138343 (Enable `f16` tests for `powf`)
- #138356 (bump libc to 0.2.171 to fix xous)
- #138371 (Update compiletest's `has_asm_support` to match rustc)
- #138404 (Cleanup sysroot locating a bit)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
I want to work on this in a followup commit, so in this commit I make it
self-contained. Contains no code changes, all functions are defined
exactly as they were in conversions.rs.
|
|
|
|
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already
have a `par_` or `try_par_` prefix I added the `hir_` after that.
|
|
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
|
|
This reduces the size of both these args, and of path segments,
so should measurably help with memory use.
|
|
Closes https://github.com/rust-lang/rust/issues/135600
Effectivly reverts https://github.com/rust-lang/rust/pull/134880
|
|
r=aDotInTheVoid
Made `Path::name` only have item name rather than full name
Closes #134853
This PR makes `Path::name` to only have item name rather than full name, i.e. with the following code
```rust
pub mod foo {
pub struct Bar;
}
pub fn get_bar() -> foo::Bar {
foo::Bar
}
```
and running `./rustdoc ./demo.rs -wjson -Zunstable-options` gives:
```json
{
"41": {
"id": 41,
"name": "get_bar",
"inner": {
"function": {
"sig": {
"inputs": [],
"output": {
"resolved_path": {
"name": "Bar",
"id": 0,
"args": { "angle_bracketed": { "args": [], "constraints": [] }
}
}
}
}
}
}
}
}
```
_Information which isn't useful here was trimmed_
r? aDotInTheVoid
|
|
|
|
|
|
|
|
Hide `= _` as associated constant value inside impl blocks
Closes #134320.
### Before:
<img src="https://github.com/user-attachments/assets/19d28811-45d2-4563-9726-f40c6af411c6" width="300"> <img src="https://github.com/user-attachments/assets/1ecf8764-97ce-47f0-87fa-3b174d2fc578" width="300">
### After:
<img src="https://github.com/user-attachments/assets/6408c4ca-b1c4-42e4-884b-248833a4865f" width="300"> <img src="https://github.com/user-attachments/assets/df2f6981-16f6-409f-8abb-73c0a4a71d6b" width="300">
r? `@fmease`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rustc_target reexports a lot of things that are in rustc_abi, but
that will be over soon and now is probably a good time to switch.
Uses of rustc_target remain where they inquire about the target tuple.
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: use strategic boxing to shrink `clean::Item`
* `inline_stmt_id` is never a cross-crate DefId, so save space by not storing it.
* Instead of two inner boxes for `Item`, use one.
|
|
|
|
|
|
Rustdoc often has to special-case `Self` because it is, well, a special
type of generic parameter (although it also behaves as an alias in
concrete impls). Instead of spreading this special-casing throughout the
code base, create a new variant of the `clean::Type` enum that is for
`Self` types.
This is a refactoring that has almost no impact on rustdoc's behavior,
except that `&Self`, `(Self,)`, `&[Self]`, and other similar occurrences
of `Self` no longer link to the wrapping type (reference primitive,
tuple primitive, etc.) as regular generics do. I felt this made more
sense since users would expect `Self` to link to the containing trait or
aliased type (though those are usually expanded), not the primitive that
is wrapping it. For an example of the change, see the docs for
`std::alloc::Allocator::by_ref`.
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
|
|
As suggested [on zulip][1], there's no need to use `GenericBound` here,
as the only bound a lifetime can have is that it outlives other
lifetimes.
While we're making breaking changes here, I also renamed it from using
"region" to "lifetime", as this is more user-aligned. See [this
comment][2] for details.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.60ItemEnum.3A.3AOpaqueTy.60/near/448871430
[2]: https://github.com/rust-lang/rust/issues/100961#issuecomment-2206565556
|
|
|
|
|
|
|
|
r=compiler-errors
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup
Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.
Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.
---
Old terminology (HIR, rustdoc):
```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
├── `Ty`: (associated) type binding
└── `Const`: associated const equality (constraint)
```
Old terminology (AST, abbrev.):
```
`AssocConstraint`
├── `Bound`
└── `Equality`
├── `Ty`
└── `Const`
```
New terminology (AST, HIR, rustdoc):
```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
├── `Ty`: associated type equality constraint OR associated type binding (for short)
└── `Const`: associated const equality constraint OR associated const binding (for short)
```
r? compiler-errors
|
|
|
|
Almost all callers want this anyway, and now we can use it to also return fed bodies
|
|
|
|
|
|
|
|
source order even if early-bound params are present
|
|
|
|
|
|
|
|
|