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

Remove condition tutorial from doc index #12549

Closed
brson opened this issue Feb 25, 2014 · 7 comments
Closed

Remove condition tutorial from doc index #12549

brson opened this issue Feb 25, 2014 · 7 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Feb 25, 2014

This tutorial no longer exists.

@adrientetar
Copy link
Contributor

Sounds like #12539, but maybe we could repurpose this issue as to write a new one?

@aochagavia
Copy link
Contributor

Why would you want to write a new condition tutorial if there aren't conditions?

@pnkfelix
Copy link
Member

The original condition guide actually covered four separate topics on handling errors/exceptions ("or other rare events"), not just conditions:

  • Options
  • Results
  • Failure
  • Conditions

I suspect that once Conditions were gone, @alexcrichton figured there was little point in keeping the guide, though I suspect there might be some value in documenting the distinction between handling errors via Result-chaining versus Failure.

@adrientetar
Copy link
Contributor

The recent PR #13499 is relevant, someone suggested putting parts of it in an error handling tutorial.

We should settle on whether we want a tutorial to deal with this or if we want to defer to rustdoc docblocks.
The main advantage of adding back a guide being that we would have a centralized place to present all forms of error handling.

@brson
Copy link
Contributor Author

brson commented Apr 18, 2014

I would like an error handling guide.
On Apr 17, 2014 6:50 PM, "Adrien Tétar" notifications@github.com wrote:

The recent PR #13499 #13499 is
relevant, someone suggested putting parts of it in an error handling
tutorial.

We should settle on whether we want a tutorial to deal with this or if we
want to defer to rustdoc docblocks.
The main advantage of adding back a guide being that we would have a
centralized place to present all forms of error handling.


Reply to this email directly or view it on GitHubhttps://github.com//issues/12549#issuecomment-40780619
.

@steveklabnik
Copy link
Member

This has been completed, can someone close?

@alexcrichton
Copy link
Member

Horray!

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
…Veykril

feat: Go to implementation of trait methods

try goto where the trait method implies,  rust-lang#4558
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 4, 2024
…atting-false-positive-when-commented-else, r=Alexendoo

fix: `suspicious_else_formatting` false positive when else is included …

This PR addresses an issue where invalid suggestions are generated for `if-else` formatting if comments contain the keyword `else`.

The root of the problem is identified [here](https://github.com/rust-lang/rust-clippy/blob/95c62ffae9bbce793f68a6f1473e3fc24af19bdd/clippy_lints/src/formatting.rs#L217). Specifically, when a comment contains the word `else`, the lint mistakenly interprets it as part of an `if-else` clause. This misinterpretation leads to an incorrect splitting of the snippet, resulting in erroneous suggestions.

fixes: rust-lang#12497

changelog: [`suspicious_else_formatting`]: Fixes invalid suggestions when comments include word else
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

6 participants