rustdoc: Fix cosmetic issues when reporting unresolved paths in `broken_intra_doc_links`
Fix some minor issues with how the `rustdoc::broken_intra_doc_links` lint labels unresolved items:
- [`a469a4a`] For unresolved "extern prelude" links like `::unresolved::item`
- Previously: ```no item named `` in scope```
- Now: ```no item named `unresolved` in scope```
- [`eeb96fa`] Some malformed paths are now accounted for, for example:
- `std:::path`
- Previously: ```no item named `std:` in scope```
- Now: `has invalid path separator`
- `std::::path`
- Previously: ```no item named `` in scope```
- Now: `has invalid path separator`
This PR is broken down into a few commits with their own descriptions, which I hope makes reviewing easier!
Fixesrust-lang/rust#141095
[`a469a4a`]: https://github.com/rust-lang/rust/commit/a469a4ae638200c264c553e72204335e20d661a1
[`eeb96fa`]: https://github.com/rust-lang/rust/commit/eeb96fab7c7882dca4c48aa8b5817e4acbf0d7d2
- Check whether an unresolved path is in fact invalid. This prevents rustdoc
from emitting nonsensical diagnostics like:
- "no item named `std:` in scope"
- "no item named `` in scope"
Instead rustdoc will now say "has invalid path separator" (the same message
from `MalformedGenerics::InvalidPathSeparator`)
This is done by checking whether each path segment is empty or contains extra ":"
after it's been split by the path separator "::".
- Add a dedicated test `tests/rustdoc-ui/intra-doc/invalid-path-separator.rs`
for this.
- Some unrelated test snapshots have been updated because of this new check.
When an unconstrained type or lifetime parameter is detected in an
`impl`, provide more specific help based on its usage:
- If the parameter is entirely unused, suggest removing it.
- If it is used in the `impl` body but not the `Self` type, suggest
including it in the `Self` type and the struct definition.
This also adds a comprehensive UI test for these cases.
- Add a check while trying to resolve parents, so that for links like
[`::unresolved::path`], rustdoc will say:
"no item named `unresolved` in scope"
instead of:
"no item named `` in scope"
- Update corresponding test
add `cfg(target_object_format = "...")`
tracking issue: https://github.com/rust-lang/rust/issues/152586
I'm implementing the predicate as `target_object_format`, because that's what is useful to me (for testing `#[link_section = "..."]` where `mach-o` has some extra restrictions) and maps cleanly to the `BinaryFormat` enum that is used internally. There is still room for a future `target_executable_format` when there is a use case.
cc @joshtriplett as the lang sponsor of this feature, @workingjubilee as the author of the proposal.
r? JonathanBrouwer a sidequest from the sidequest that is https://github.com/rust-lang/rust/pull/155065
Port lint attributes to attribute parser
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152369)*
Tracking issue: rust-lang/rust#131229
Ports `#[allow]`, `#[deny]`, `#[expect]`, `#[forbid]`, and `#[warn]` to being parsed attrs
I tried my best to make this PR as small as possible, it was difficult. I hope it isn't too difficult to review
r? @JonathanBrouwer
r? @jdonszelmann
also removes E0452 and splits
`tests/rustdoc-ui/lints/renamed-lint-still-applies` into 2 tests
this is because of delayed warn lint being lost on compiler aborting on
error
rustdoc_missing_doc_code_examples: lint on macro_rules macros
part of rust-lang/rust#154640
accidentally built this on top of rust-lang/rust#154644, but since that PR is already approved it should be fine if we just wait for it to be merged.
r? @GuillaumeGomez
Fix ice in rustdoc of private reexport
Fixesrust-lang/rust#154383
The root cause is rustdoc could still try to resolve links for source docs that resolver did not cache in `ResolveDocLinks::Exported` mode. The test case will not crash with `--document-private-items` option, which will use `ResolveDocLinks::All`.
The fix makes rustdoc skip link resolution based on the source `DefId` of each doc fragment, so its behavior stays aligned with resolver's logic here: https://github.com/chenyukang/rust/blob/dc5cb1719eed6ac9275fe93d914d32141606b2ac/compiler/rustc_resolve/src/late.rs#L685
Don't emit rustdoc `missing_doc_code_examples` lint on impl items
@lolbinarycat realized in [this comment](https://github.com/rust-lang/rust/pull/153964#discussion_r2953956702) that we weren't testing some cases for the `missing_doc_code_examples` lint. Turns out that it was not handling this case well. =D
So in short: `missing_doc_code_examples` lint should not be emitted on impl items and this PR fixes that.
r? @lolbinarycat
Provide more context on type errors in const context
- On `const` and `static` point at the type (like we do for let bindings)
- On fn calls, point at const parameter in fn definition
- On type, point at const parameter in type definition
- On array type lengths, explain that array length is always `usize`
- On enum variant discriminant, mention `repr`
- On default field value using type parameter, provide more context (Fixrust-lang/rust#147748)
These options don't behave reasonably when combined right now, and there
are no tests and no docs for how they should.
For the short term, make this a fatal error. If we decide to assign this
some semantics, then we can do that at any time.
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
Redddy