Skip to content
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

doc, explicit Result types #16096

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
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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