Because in the case of for example
pub fn my_fn3(f: impl FnMut()) {}
we want to keep `()` even if it is empty since that matches e.g. Rust
syntax requirements.
They show up in three places: once as `Option<Box<GenericArgs>>`, once
as `Box<GenericArgs>`, and once as `GenericArgs`. The first option is
best. It is more compact because generic args are often missing. This
commit changes the latter two to the former.
Example output, before and after, for the `AssocItemConstraint` change:
```
{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}},"binding":{...}}
{"name":"Offset","args":null,"binding":{...}}
```
Example output, before and after, for the `Type::QualifiedPath` change:
```
{"qualified_path":{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}}, ...}}
{"qualified_path":{"name":"Offset","args":null, ...}}
```
This reduces JSON output size, but not by much (e.g. 0.5%), because
`AssocItemConstraint` and `Type::QualifiedPath` are uncommon.
A path without generic args, like `Reader`, currently has JSON produced
like this:
```
{"path":"Reader","id":286,"args":{"angle_bracketed":{"args":[],"constraints":[]}}}
```
Even though `types::Path::args` is `Option` and allows for "no args",
instead it gets represented as "empty args". (More like `Reader<>` than
`Reader`.)
This is due to a problem in `clean::Path::from_clean`. It only produces
`None` if the path is an empty string. This commit changes it to also
produce `None` if there are no generic args. The example above becomes:
```
{"path":"Reader","id":286,"args":null}
```
I looked at a few examples and saw this reduce the size of the JSON
output by 3-9%.
The commit also adds an assertion that non-final segments don't have any
generics; something the old code was implicitly relying on.
Note: the original sin here is that `clean::PathSegment::args` is not an
`Option`, unlike `{ast,hir}::PathSegment::args`. I want to fix that, but
it can be done separately.
We move the vectorcall ABI tests into their own file which is now
only run on x86-64, while replacing them with rust-cold ABI tests
so that aarch64 hosts continue to test an unstable ABI.
A better solution might be cross-compiling or something but
I really don't have time for that right now.
jsondocck: Require command is at start of line
In one place we use `///``@``` instead of `//``@`.`` The test-runner allowed it, but it probably shouldn't. Ran into by ``@lolbinarycat`` in https://github.com/rust-lang/rust/pull/132748#issuecomment-2816469322:
```
error: unknown disambiguator `?(`
##[error] --> /checkout/tests/rustdoc-json/fns/return_type_alias.rs:3:25
|
3 | ///@ set foo = "$.index[?(``@.name=='Foo')].id"``
| ^^
|
```
Maybe it's also worth erroring on this like we added in #137103
r? ``@GuillaumeGomez``
`#[target_feature]` attributes refer to a target-specific list of
features. Enabling certain features can imply enabling other features.
Certain features are always enabled on certain targets, since they are
required by the target's ABI. Features can also be enabled indirectly
based on other compiler flags.
Feature information is ultimately known to `rustc`. Rather than force
external tools to track it -- which may be wildly impractical due to
`-C target-cpu` -- have `rustdoc` output `rustc`'s feature data.
rustdoc-json: Add tests for `#[repr(...)]`
Works towards #137645 and #81359
Based on #138018, but with only the test changes. CC ```@obi1kenobi```
r? ```@GuillaumeGomez```
make precise capturing args in rustdoc Json typed
close#137616
This PR includes below changes.
- Add `rustc_hir::PreciseCapturingArgKind` which allows the query system to return a arg's data.
- Add `rustdoc::clean::types::PreciseCapturingArg` and change to use it.
- Add `rustdoc-json-types::PreciseCapturingArg` and change to use it.
- Update `tests/rustdoc-json/impl-trait-precise-capturing.rs`.
- Bump `rustdoc_json_types::FORMAT_VERSION`.
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
`CheckAttrVisitor::check_doc_keyword` checks `#[doc(keyword = "..")]`
attributes to ensure they are on an empty module, and that the value is
a non-empty identifier.
The `rustc::existing_doc_keyword` lint checks these attributes to ensure
that the value is the name of a keyword.
It's silly to have two different checking mechanisms for these
attributes. This commit does the following.
- Changes `check_doc_keyword` to check that the value is the name of a
keyword (avoiding the need for the identifier check, which removes a
dependency on `rustc_lexer`).
- Removes the lint.
- Updates tests accordingly.
There is one hack: the `SelfTy` FIXME case used to used to be handled by
disabling the lint, but now is handled with a special case in
`is_doc_keyword`. That hack will go away if/when the FIXME is fixed.
Co-Authored-By: Guillaume Gomez <guillaume1.gomez@gmail.com>
As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.
This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver
These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.
Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.
It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.
This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519https://github.com/rust-lang/rust/issues/44874
r? @wesleywiser
