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

Box<Vec<T>> warning triggered spuriously #31

Closed
maurer opened this issue Feb 18, 2015 · 3 comments
Closed

Box<Vec<T>> warning triggered spuriously #31

maurer opened this issue Feb 18, 2015 · 3 comments

Comments

@maurer
Copy link

maurer commented Feb 18, 2015

The Box<Vec<T>> warning appears to be being triggered when I box a closure (necessary in this case to make the struct Sized).

src/native_types.rs:93:13: 93:65 note: Vec<T> is already on the heap, Box<Vec<T>> makes an extra allocation
src/native_types.rs:93   pub run : Box<Fn(Vec<HValue>) -> Vec<HValue> + 'static + Send>
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@pythonesque
Copy link
Contributor

This is (or should be) fixed now.

@llogiq
Copy link
Contributor

llogiq commented May 8, 2015

I'll add a test to tests/compile-fail/box_vec.rs. If successful, I'll close.

llogiq added a commit that referenced this issue May 8, 2015
@llogiq
Copy link
Contributor

llogiq commented May 8, 2015

Yep, it's no longer triggered. Closing.

@llogiq llogiq closed this as completed May 8, 2015
yaahc pushed a commit to yaahc/rust-clippy that referenced this issue Mar 14, 2019
Work around \-characters on Windows for now
bors added a commit that referenced this issue Jun 30, 2021
New lint: `disallowed_script_idents`

This PR implements a new lint to restrict locales that can be used in the code,
as proposed in #7376.

Current concerns / unresolved questions:

- ~~Mixed usage of `script` (as a Unicode term) and `locale` (as something that is easier to understand for the broad audience). I'm not sure whether these terms are fully interchangeable and whether in the current form it is more confusing than helpful.~~ `script` is now used everywhere.
- ~~Having to mostly copy-paste `AllowedScript`. Probably it's not a big problem, as the list of scripts is standardized and is unlikely to change, and even if we'd stick to the `unicode_script::Script`, we'll still have to implement custom deserialization, and I don't think that it will be shorter in terms of the amount of LoC.~~ `unicode::Script` is used together with a filtering deserialize function.
- Should we stick to the list of "recommended scripts" from [UAX #31](http://www.unicode.org/reports/tr31/#Table_Recommended_Scripts) in the configuration?

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: ``[`disallowed_script_idents`]``

r? `@Manishearth`
bors added a commit that referenced this issue Jun 30, 2021
New lint: `disallowed_script_idents`

This PR implements a new lint to restrict locales that can be used in the code,
as proposed in #7376.

Current concerns / unresolved questions:

- ~~Mixed usage of `script` (as a Unicode term) and `locale` (as something that is easier to understand for the broad audience). I'm not sure whether these terms are fully interchangeable and whether in the current form it is more confusing than helpful.~~ `script` is now used everywhere.
- ~~Having to mostly copy-paste `AllowedScript`. Probably it's not a big problem, as the list of scripts is standardized and is unlikely to change, and even if we'd stick to the `unicode_script::Script`, we'll still have to implement custom deserialization, and I don't think that it will be shorter in terms of the amount of LoC.~~ `unicode::Script` is used together with a filtering deserialize function.
- Should we stick to the list of "recommended scripts" from [UAX #31](http://www.unicode.org/reports/tr31/#Table_Recommended_Scripts) in the configuration?

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: ``[`disallowed_script_idents`]``

r? `@Manishearth`
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

No branches or pull requests

3 participants