Skip to content

doc, explicit Result types #16096

New issue

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

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

Already on GitHub? # to your account

Closed
jxs opened this issue Jul 30, 2014 · 6 comments
Closed

doc, explicit Result types #16096

jxs opened this issue Jul 30, 2014 · 6 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@jxs
Copy link
Contributor

jxs commented Jul 30, 2014

regarding #16075
currently in std doc there are methods which return Result, which can be confusing at first sight.
Would be great if the function showed upfront the Result<T, E>

@steveklabnik steveklabnik added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jan 27, 2015
@tomjakubowski
Copy link
Contributor

I don't understand what this issue is about. Is it that types like fmt::Result should appear qualified by their module name, because they might be confused with other Result types?

One partial solution might be a pass that walks the crate and finds any types in signatures that have the same name but different definitions (e.g. fmt::Result and result::Result), and figuring out how many levels of path segments are needed to qualify each of their names until there's no ambiguity.

@steveklabnik
Copy link
Member

I believe that it's about Result<Foo, Bar> rather than Result<T, E> appearing in type signatures, but I'm not sure.

@tomjakubowski
Copy link
Contributor

Reading the linked issue it looks like my understanding was right. There's another issue like what you're describing (substituting type parameters in default methods) #14072

@alexcrichton
Copy link
Member

Yes this issue has to do with prefixes not being displayed, even when they're present in the source. For example you only see Result<usize> here

@steveklabnik
Copy link
Member

Triage: no change.

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 21, 2017
@Mark-Simulacrum
Copy link
Member

Closing in favor of #42066; which is more general than this. Thanks!

lnicola pushed a commit to lnicola/rust that referenced this issue Jan 3, 2024
fix: update VSCode rust-panic problem matcher

Corrected the `rust-panic` task problem matcher for the VSCode Extension to match the new panic message pattern.

From:
```
thread 'main' panicked at 'PANIC_MESSAGE', src/main.rs:L:C
```
To:
```
thread 'main' panicked at src/main.rs:L:C:
PANIC_MESSAGE
```
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants