Skip to content

Implement #[deriving(Show)] #12066

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 6 commits into from
Feb 8, 2014
Merged

Implement #[deriving(Show)] #12066

merged 6 commits into from
Feb 8, 2014

Conversation

huonw
Copy link
Member

@huonw huonw commented Feb 6, 2014

  • Convert the formatting traits to &self rather than _: &Self
  • Rejig syntax::ext::{format,deriving} a little in preparation
  • Implement #[deriving(Show)]

@flaper87
Copy link
Contributor

flaper87 commented Feb 6, 2014

This is amazing, really. Thanks!

@huonw
Copy link
Member Author

huonw commented Feb 7, 2014

(Addressed comments; can squash and rebase post-review.)

@alexcrichton
Copy link
Member

looks great! r=me with squashings

bors added a commit that referenced this pull request Feb 8, 2014
- Convert the formatting traits to `&self` rather than `_: &Self`
- Rejig `syntax::ext::{format,deriving}` a little in preparation
- Implement `#[deriving(Show)]`
@bors bors closed this Feb 8, 2014
@bors bors merged commit b89afe2 into rust-lang:master Feb 8, 2014
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jan 11, 2024
Don't look for safety comments in doc tests

Fixes rust-lang#12048.

What happened in the linked issue is that the lint checks for lines that start with `//` and have `SAFETY:` somewhere in it above the function item.
This works for regular comments, but when the `//` is the start of a doc comment (e.g. `/// // SAFETY: ...`) and it's part of a doc test (i.e. within \`\`\`), we probably shouldn't lint that, since the user most likely meant to refer to a different node than the one currently being checked. For example in the linked issue, the safety comment refers to `unsafe { *five_pointer }`, but the lint believes it's part of the function item.

We also can't really easily test whether the `// SAFETY:` comment within a doc comment is necessary or not, since I think that would require creating a new compiler session to re-parse the contents of the doc comment. We already do this for one of the doc markdown lints, to look for a main function in doc tests, but I don't know how to feel about doing that in more places, so probably best to just ignore them?

changelog: [`unnecessary_safety_comment`]: don't look for safety comments in doc tests
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.

4 participants