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.

Sign up for GitHub

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

Jump to bottom

Add overloadable deref traits #11780

Closed
brson opened this issue Jan 24, 2014 · 3 comments
Closed

Add overloadable deref traits #11780

brson opened this issue Jan 24, 2014 · 3 comments
Labels
P-medium Medium priority
Milestone
1.0

Comments

@brson
Copy link
Contributor

brson commented Jan 24, 2014

I don't see an issue for this. Nominating.
@pnkfelix
Copy link
Member

Accepted for 1.0, P-high

@nikomatsakis
Copy link
Contributor

cc me

@nikomatsakis
Copy link
Contributor

Dup of #7141

flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 16, 2023
@bors
Auto merge of rust-lang#11780 - Jacherr:vec-allocator-nolint, r=xFrednet
6be0f74 
Disable `vec_box` when using different allocators

Fixes rust-lang#7114

This PR disables the `vec_box` lint when the `Box` and `Vec` use different allocators (but not when they use the same - custom - allocator).

For example - `Vec<Box<i32, DummyAllocator>>` will disable the lint, and `Vec<Box<i32, DummyAllocator>, DummyAllocator>` will not disable the lint.

In addition, the applicability of this lint has been changed to `Unspecified` due to the automatic fixes potentially breaking code such as the following:

```rs
fn foo() -> Vec<Box<i32>> { // -> Vec<i32>
  vec![Box::new(1)]
}
```

It should be noted that the `if_chain->let-chains` fix has also been applied to this lint, so the diff does contain many changes.

changelog: disable `vec_box` lint when using nonstandard allocators
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P-medium Medium priority
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
3 participants
@brson @nikomatsakis @pnkfelix