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

#[deriving] should copy lint attributes from the original item #13054

Closed
lifthrasiir opened this issue Mar 21, 2014 · 1 comment
Closed

#[deriving] should copy lint attributes from the original item #13054

lifthrasiir opened this issue Mar 21, 2014 · 1 comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut.

Comments

@lifthrasiir
Copy link
Contributor

Otherwise it can be very annoying to use lint-affected items selectively. For example, the following code tries to use an unstable item X from a stable item A, but boilerplates generated from #[deriving(Clone)] do not have #[allow(unstable)] attached, so it fails to compile. Currently the only way available is to manually add impls with the proper lint attributes.

#[deny(unstable)];

#[allow(unstable)]
#[unstable]
#[deriving(Clone)]
struct X;

#[allow(unstable)]
#[deriving(Clone)]
struct A { x: X }

fn main() { }
@steveklabnik steveklabnik added the A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. label Jan 23, 2015
bors added a commit that referenced this issue Oct 20, 2015
The attributes are copied from the item for which the trait impl is derived

I think now we can close these two issues:
#13054 - `allow`, `deny` etc. were already copied, now `stable` and `unstable` are copied as well.
#18969 - I'm not sure this is needed, insta-stability were good enough so far, copied stability will be better. Nonetheless, it can be subsumed by some more general mechanism for supplying arbitrary not necessarily stability related attributes (for example `inline`) to derived impls and their methods (I haven't found an open issue for such mechanism).

r? @alexcrichton
@petrochenkov
Copy link
Contributor

It was resolved by #29152

flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 3, 2024
Suggest `Option<&T>` instead of `&Option<T>`

closes rust-lang#13054

```rust
// bad code
fn foo(a: &Option<T>) {}
fn bar(&self) -> &Option<T> {}

// Use instead
fn foo(a: Option<&T>) {}
fn bar(&self) -> Option<&T> {}
```

Handles argument types and return types in functions, methods, and closures with explicit types.  Honors `avoid_breaking_exported_api` parameter.

See this great [YouTube video](https://www.youtube.com/watch?v=6c7pZYP_iIE) with the in-depth explanation.

### Open Questions
These are not blocking, and could be done in separate PRs if needed.
* [ ] Should `&Option<Box<T>>` be suggested as `Option<&T>` -- without the box?  Handled by [clippy::borrowed_box](https://rust-lang.github.io/rust-clippy/master/index.html#/borrowed_box)
* [ ] Should `&Option<String>` be suggested as `Option<&str>` -- using de-refed type?

### Possible Future Improvements
These cases might also be good to handle, probably in a separate PR.

```rust
fn lambdas() {
  let x = |a: &Option<String>| {};
  let x = |a: &Option<String>| -> &Option<String> { todo!() };
}

fn mut_ref_to_ref(a: &mut &Option<u8>) {}
```

changelog: [`ref_option`]: Suggest `Option<&T>` instead of `&Option<T>`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut.
Projects
None yet
Development

No branches or pull requests

4 participants