Skip to content

Fix repeated module documentation #13812

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 28, 2014
Merged

Fix repeated module documentation #13812

merged 1 commit into from
Apr 28, 2014

Conversation

alxgnon
Copy link
Contributor

@alxgnon alxgnon commented Apr 28, 2014

This is a quick fix for repeated documentation descriptions in certain modules.
Following is a list of the faulty modules I found. I ran pcregrep -r -M "<p>(.+)\n\1" doc on the html documentation to help identify them.

After a little testing, I discovered that moving the documentation inside (//!) instead of outside (///) modules fixed the immediate problem. I went through the trouble of moving the documentation, and with this commit there are no more repeated descriptions within those faulty modules.

This does not fix the underlying problem though. We should look into why having the documentation outside instead of inside caused the descriptions to be repeated. I will create a separate issue with my findings on the subject if necessary.
In the meantime, this simple fix should be enough.

bors added a commit that referenced this pull request Apr 28, 2014
This is a quick fix for repeated documentation descriptions in certain modules.
Following is a list of the faulty modules I found. I ran `pcregrep -r -M "<p>(.+)\n\1" doc` on the html documentation to help identify them.

- [rustuv::uvio](http://static.rust-lang.org/doc/master/rustuv/uvio/index.html)
- [rustuv::uvll](http://static.rust-lang.org/doc/master/rustuv/uvll/index.html)
- [std::rt::backtrace](http://static.rust-lang.org/doc/master/std/rt/backtrace/index.html)
- [std::rt::env](http://static.rust-lang.org/doc/master/std/rt/env/index.html)
- [std::rt::global_heap](http://static.rust-lang.org/doc/master/std/rt/global_heap/index.html)
- [std::rt::local_heap](http://static.rust-lang.org/doc/master/std/rt/local_heap/index.html)
- [std::rt::rtio](http://static.rust-lang.org/doc/master/std/rt/rtio/index.html)
- [std::rt::task](http://static.rust-lang.org/doc/master/std/rt/task/index.html)
- [std::rt::thread](http://static.rust-lang.org/doc/master/std/rt/thread/index.html)
- [std::rt::unwind](http://static.rust-lang.org/doc/master/std/rt/unwind/index.html)
- [syntax::parse::classify](http://static.rust-lang.org/doc/master/syntax/parse/classify/index.html)
- [syntax::parse::common](http://static.rust-lang.org/doc/master/syntax/parse/common/index.html)

After a little testing, I discovered that moving the documentation inside (`//!`) instead of outside (`///`) modules fixed the immediate problem. I went through the trouble of moving the documentation, and with this commit there are no more repeated descriptions within those faulty modules.

This does not fix the underlying problem though. We should look into why having the documentation outside instead of inside caused the descriptions to be repeated. I will create a separate issue with my findings on the subject if necessary.
In the meantime, this simple fix should be enough.
@bors bors closed this Apr 28, 2014
@bors bors merged commit 6c41253 into rust-lang:master Apr 28, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 5, 2023
… r=Veykril

feat: make inlay hints insertable

Part of rust-lang#13812

This PR implements text edit for inlay hints. When an inlay hint contain text edit, user can "accept" it (e.g. by double-clicking in VS Code) to make the hint actual code (effectively deprecating the hint itself).

This PR does not implement auto import despite the original request; text edits only insert qualified types along with necessary punctuation. I feel there are some missing pieces to implement efficient auto import (in particular, type traversal function with early exit) so left it for future work. Even without it, user can use `replace_qualified_name_with_use` assist after accepting the edit to achieve the same result.

I implemented for the following inlay hints:
- top-level identifier pattern in let statements
- top-level identifier pattern in closure parameters
- closure return type when its has block body

One somewhat strange interaction can be observed when top-level identifier pattern has subpattern: text edit inserts type annotation in different place than the inlay hint. Do we want to allow it or should we not provide text edits for these cases at all?

```rust
let a /* inlay hint shown here */ @ (b, c) = foo();
let a @ (b, c) /* text edit inserts types here */ = foo();
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants